james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Darrell DeBoer" <li...@bigdaz.com>
Subject Re: Version numbers...
Date Sat, 12 Jan 2002 00:47:22 GMT
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" <danny@thought.co.uk>
To: "James Developers List" <james-dev@jakarta.apache.org>
Sent: Saturday, January 12, 2002 2:57 AM
Subject: RE: Version numbers...


> Should we vote on this?
>
> > -----Original Message-----
> > From: Danny Angus [mailto:danny@thought.co.uk]
> > 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:james-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> > <mailto:james-dev-help@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
<mailto:james-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:james-dev-help@jakarta.apache.org>


--
To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>


Mime
View raw message