G'day 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 ?" ).
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. ciao Daz ----- Original Message ----- From: "Danny Angus" <[EMAIL PROTECTED]> To: "James Developers List" <[EMAIL PROTECTED]> Sent: Saturday, January 12, 2002 2:57 AM Subject: RE: Version numbers... > Should we vote on this? > > > -----Original Message----- > > From: Danny Angus [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, January 10, 2002 11:50 AM > > To: James Developers List > > Subject: Version numbers... > > > > > > I'd like to propose that we use a version number system like that used by > > bugzilla, namely that the head of CVS have an even minor number and > > milestone releases have the opposite, in addition "nightly" releases would > > have the same version number as the current CVS. > > > > Thus CVS is currently 2.0a2, when we make a milestone release it would be > > released as 2.0a3 and CVS would advance to 2.0a4, that way there > > would be no > > confusion between bugs reported against released versions and > > bugs reported > > against nightly builds/cvs. > > > > this is the explanation from bugzilla.. > > > > "We only place tarballs of even-numbered minor versions on the FTP server. > > The installed version on bugzilla.mozilla.org (and the most recent CVS > > version, which is a slightly newer version than the installed version) > > always have an odd-numbered minor version. If you want to get exactly the > > code that mozilla.org is running, you're out of luck (they make internal > > patches just like everyone else), but you can get pretty close by > > using CVS, > > and the minor version number will be odd. If you want a more > > stable release, > > you can use a tarball, and the minor version number will be even. " > > > > d. > > > > > > -- > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
