Doug Morris <[EMAIL PROTECTED]> writes:
> "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.
>
> The revision numbers already have meaning.
I didn't say they didn't have meaning, just that they don't have _absolute_
meaning. If I run `scan -version` and it tells me 1.0.1, that doesn't mean
I'm running the same version as someone else whose scan prints out the same
string. I'm likely not to remember if the source used to compile a
paricular copy of nmh on one of my many machines came from an FTP tarball or
from CVS (or from a locally tarred copy of source from CVS). So if an nmh
user complains about a "1.0.1" bug and I can't reproduce it on one of my
machines where -version also gives that string, I don't know whether or not
I'm comparing apples and oranges.
> 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.
But we don't care. That's what I'm saying -- I think a line should be drawn
between developer versions and released versions. I don't think developer
versions should use the same version numbers as released ones.
Under my proposed versioning system, if someone complains about a bug in
1.0.3 we say "Too bad, that's a developer version -- try getting the latest
CVS source and see if it goes away." If they complain about a bug in 1.0.2,
however, we know damn well they're talking about a public release -- we
don't have to ask them first, "Now, did you get your 1.0.2 via FTP or CVS?"
> >Until now, 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.
No. Like I said, I'm drawing a line between developer versions and public
versions. The assumption is that developers update their source from
time-to-time, and they won't report problems unless they make sure they
exist in the _latest_ version of the CVS source.
The only issue is the confusion between different versions of _released_
version numbers. If you change the version number just before and just
after making tarballs, it's not a concern.
> 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
That's not what the website says:
The source is available using anonymous _cvs_ or via _ftp_.
There's no mention that non-developers are only supposed to go the FTP
route. In fact, FTP is the _second_ mentioned way to get the source, not
the first. Unless you eliminate anonymous CVS access, it will be a route
some end-users will take to get the code.
> (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.
Yes, but if someone reports a problem with a specific version number, how do
we _know_ that they have something "in the middle"? We don't, unless they
mention "I got this copy of my source via CVS" or we ask everyone where they
got their source before we answer their questions. Why not encode that
information in the version number to easily eliminate all these problems?
> 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.
There are reasons for end-users to want the latest CVS source. During the
time between the releases of 1.0.1 and 1.0.2, there were multiple instances
I'm aware of of end-users wanting the latest CVS source to get particular
bug fixes. If those users later complain about problems, it'd be nice to
identify by means of the version number (which anyone with half a brain will
mention when reporting a bug) that they're using "at-your-own-risk" source.
> 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.
Unfortunately, right now it doesn't reflect actual releases. It reflects
actual releases plus _all_ CVS versions up until the next actual release.
> 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).
Yes, as I said in another email to the list, my Linux kernel analogy was
apparently a bit broken. I just wanted to borrow the idea of "even" meaning
public releases and "odd" meaning developer versions.
> 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 website should be modified to reflect this.
> 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.
Again, as I said in another email, I dislike 1.0.3-dev (or 1.0.3-beta or
1.0.3-pre) because it implies that the next released version will be 1.0.3,
and this may not be the case. It may be 1.1[.0].
If you're violently against the even/odd version number dichotomy, I could
live with changing the version number to "1.0.2+". In fact, that
("nmh-1.0.1+") is what I've been calling my "stow" directories of developer
versions of 1.0.1 (that were modified after the 1.0.1 tarball release).
With that convention, you don't make any false implications about the next
version number to be released (or make weird jumps from 1.0.3-dev to 1.1.0).
However, there's more opportunity for confusion with the plus sign being a
significant character. Someone not familiar with the convention (or even
someone who is) might inadverantly drop it and just say "1.0.2". On the
other hand, there's little opportunity for confusion between "1.0.2" and
"1.0.3".
-----------------------------------------------------------------------
Dan Harkless | To prevent SPAM contamination, please
[EMAIL PROTECTED] | do not post this private email address
SpeedGate Communications, Inc. | to the USENET or WWW. Thank you.
