On Sat, 12 Jan 2002 11:47, Darrell DeBoer wrote: > Actually (after voting +1), an alternative would be to just have the > version number in CVS something like "2.0a2-unreleased" (or even > "2.0a2-cvs"), and simply remove the "unreleased"/"cvs" extension when the > build is formally released. This would prevent any confusion which may > arise from builds going "missing" (ie "where can I download 2.0a3 ?" ).
+1 > Even better would be to attach a unique number to each commit - where I > work we have a changelog file, which *must* be updated with every CVS > commit, including providing a new "build" number and a log a what was > changed. The change log ( a simple XML file) is then parsed by an Ant task > during the build, and the constants file is updated with the build number. > This way, we can tell *exactly* which build was being used for a bug > report. > > I'd be happy to get a commit-changelog file working, as long as committers > are willing to update it when they make changes. The way I work is I to > enter my changes into the changelog once I'm happy with everything, and > then Cut&Paste that entry as my CVS commit log message. This gives us a > nice historical view of the CVS commit log messages, from within the CVS > tree. Alternatively you could go the opposite way. I am not sure if I fully got this working but in tthe phoenix project I used a task to generate a XML ChangeLog based on the CVS logs. However instead of directly using this I tended to clean/simply/munge the changes into the real ChangeLog. -- Cheers, Pete ------------------------------------------------------------ militant agnostic: i don't know, and you don't know either. ------------------------------------------------------------ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
