"Dan Harkless" wrote:
>Howdy. I still feel very strongly that we should up the nmh version number
>in the CVS source just after releasing each tarball, so that the version
>numbers of the public releases really have an absolute meaning. Until now,
The revision numbers already have meaning. The version number in
all releases is the state of the repository at the time the release
was generated. This is tagged so it can be reproduced at a later
date. For example:
<http://www.mhost.com/cgi-bin/cvsweb/nmh/VERSION>
Look down to the previous revision at CVS Tags:
1.3 Fri Oct 29 4:32:51 1999 by doug
CVS Tags: nmh-1_0_2
Diffs to 1.2
That tag is on the revision of every file that is included in the
nmh-1.0.2 release. To reproduce the release, simply check out the
tagged version from the archive.
# this should work, but blows up with an assert in my copy of cvs
$ cvs -d mhost.com:/cvs co -r nmh-1_0_2 nmh
# this does work
$ cvs -d mhost.com/cvs co nmh
[ lots of files downloaded ]
$ cd nmh
$ cvs update -r nmh-1_0_2
cvs server: Updating .
P ChangeLog
P VERSION
cvs server: Updating config
cvs server: Updating etc
cvs server: Updating h
cvs server: Updating man
cvs server: Updating mts
cvs server: Updating mts/mmdf
cvs server: Updating mts/sendmail
cvs server: Updating mts/smtp
cvs server: Updating sbr
cvs server: Updating uip
cvs server: Updating zotnet
cvs server: Updating zotnet/bboards
cvs server: Updating zotnet/mf
cvs server: Updating zotnet/mts
cvs server: Updating zotnet/tws
$ cat VERSION
1.0.2
This means that, should some major problem come along, we can check
out that revision, patch it, and release the updated version without
disturbing (or being disturbed by) any work that's been done in
the meantime on the repository.
Upping the tag the way you've done doesn't solve the problem you're
complaining about. If someone now comes with a problem about 'revision
1.0.3', we still have no idea what day they got the revision, and have
no way of reproducing their exact set of files.
>someone could report a bug against 1.0.1 and someone else could say "I can't
>reproduce that bug" because they're running completely different versions of
>1.0.1, at least one of them obtained via CVS.
That is still a problem. Your revision change does not help, unless
we are supposed to up the revision every time someone commits code
to the repository. Doing so would occasionally have us bumping by
3-4 revisions a day.
I think you're confusing released versions with the code in the
CVS archive. The CVS archive is there for development. It is not a
software distribution mechanism (FreeBSD's CVSup aside). If someone
reports a bug with version 1.0.2, that means the release frozen at
revision 1.0.2. It's available in a tar file, and by checking out
that tagged revision from the CVS archive. Anything in the middle
is just in-development software and not a release.
If someone checks out the current CVS archive, they have no reason
to complain if there are bugs. The archive is in-development
software. It is likely to have bugs. In order to change things,
sometimes we have to break what's there. That's why we make stable
releases available via ftp.
>Therefore, I've upped the VERSION to 1.0.3. Unfortunately Doug didn't do
I think the number should be reverted to 1.0.2. This is not a new
release (the only changes are actually your notes in the ChangeLog and
the VERSION file). The number should be used to reflect actual releases.
One additional note, this is not the same method as is used in Linux
kernel development. For that, we would need a separate "cutting edge"
version at 1.1.x, while the "stable" version was still at 1.0.x. If we
were doing major code changes, this would be reasonable, but at this
point, we've done nothing more than basic code cleanup and some minor
feature modifications.
However, if you've ever checked out the archive at vger.rutgers.edu,
you'll find that checking out the 2.0 (now 2.2) revision from the CVS
archive does *not* get you the last stable kernel. It gets you the
current state of the development archive -- which may or may not be
broken. The 2.0/2.2 kernels move more slowly than the 2.1/2.3 kernels,
but their CVS archives are not guaranteed to be stable. For stability,
you get the actual releases at kernel.org (or your favorite mirror).
CVS access is for those who are hacking on the code, or want the
latest and greatest version all the time. In other words, if you're
willing to live on the edge and throw caution to the wind, then taking
whatever happens to be in the CVS archive is ok. It is not a software
delivery method for Joe User.
The only modification to VERSION that I think could make sense
(though I still think it is unnecessary) would be to tag it as
'1.0.2-dev' or something similar, with the full '1.0.3' being added
at release, and then immediately modified to '1.0.3-dev' for the
time during development. This prevents the number from skipping up
by twos, and would provide the division you seem to want between
in-development versions and releases.
-Doug
