Michael Price <mprice@atl.lmco.com> writes:
> I would like to open up a discussion on the way the CHANGES file is
> handled.
>
> Right now it, uh, isn't.
>
> I would like to propose the following change in the way we do
> things. When you commit what you know is a user-visible change then you
> also update the CHANGES file with an appropriate comment. After all, if
> you are doing something like adding new command line options or changing
> the layout of config files then there isn't much doubt about whether or
> not its going into the file so it might as well go in right away.
This seems reasonable.
The job of the release manager would then be to condense what's
already there, for the user-visible changes at least (it may be that
several entries added at different times can be condensed into one).
> Developer-visible changes are more transitory in nature and have a way
> of disappearing as fast as they arrived so I can see delaying those
> entries until the actual release.
More importantly, you can't judge an individual code change's
importance until you have all the other changes to compare it to. So
here, it really should be done all at once; otherwise the CHANGES file
will just become a copy of the 'svn log' records.
> So what does everyone think?
+1
However, you may need to watch the commit list and slap people on the
wrist a few times until we get the hang of it.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 21 03:56:59 2003