Jan Harkes <jaharkes_at_cs.cmu.edu> writes:

> I really like Debian's solution where the '~'
> character sorts before any other character including the empty string.
>
> i.e.  2.7~cvs2007... < 2.7~rc1 < 2.7

yes, but the point is to use something that almost all systems will work
with, rather than debian's flavor.

>> <rant>Long ago, the GNU project had a version number scheme, and it was
>> sufficent.  Now, for no good reason, there has arisen rc, a, b,
>> prerelease and a lot of other things.  Note that the GNU scheme didn't
>> require anyone to understand it to do the right 'earler?'
>> comparisons.</rant>
>
> That's because when you type 'gnu version number scheme' in google the
> best you can find is,
>
>     Major.Minor.Patch
>
>     Major - Not backwards compatible. - Requires conversion programs to
> 	move user data/config files into a new version. Much of the
> 	previous version is pitched and rewritten.
>     Minor - New features.
>     Patch - bug fixes
>
> Which is what I have been using up until now for lwp/rpc2/rvm (except
> that the bug-fixes are ideally none, so the patch is typically 0 so I
> ignore it.

Sure, and I agree it's underdocumetned.

> But it doesn't address snapshots (which ideally should contain enough
> detail to recreate the identical source tree from a checkout), release
> candidates, releases by a third party maintainer, or concurrent
> development on both a release and development branch etc.

Many people have simply bumped the development to the next number, like
gimp 2.3.x vs 2.2.x.  Those sort correctly _without having to understand
them_, and to me that's the point.

> If I want to have nightly builds, the major.minor.patch version scheme
> doesn't address this.

Sure, but on the dev branch you can just use iso8601 date so you have
2.6.90.20070813.  Lots of numbers, but a numbered beta for 2.7.

So my basic take is stick with numbers - they are entirely adequate.

> Right, and to correctly test them the version number should be fairly
> logical, so that it doesn't require a lot of changes to get the release
> candidate to build.

Right - just changing the number, no other changes, is best.  Hence my
request to have tarball dir name and version number match.

>> For minimal kludge, this means that the version# in configure.ac should
>> have the .90 or rcN suffix, so the version and the directory name in the
>> tarball match.
>
> I can get them to match without much trouble. The problem is that
> '2.6rcN' sorts after '2.6' (and even '2.6.1'). Debian solved it by
> treating '~' special.

This is the special casing I don't like.  I thought rcN was sufficiently
common that everyone had to deal, but if not that makes my argument for
just numbers stronger.  With just numbers, you get to define your
scheme, and then just rely on all systems to sort numbers correctly.

>> 		"prerelease" seems to be something that is a release,
>> just not declared, and claimed internally to be the release version,
>> with the release directory name.  I don't think coda needs that, and it
>> in my view causes way more trouble than it is worth.  Maybe you didn't
>> mean that, but I just had grief with that someplace else.
>
> No, I want to keep the version different up until the point that the
> release is made at which point the only thing that changes is the
> version number.

That sounds great.

>>   publicizing where the cvs commit list is so people can subscribe
>
> Follow the 'development' link at the top of http://www.coda.cs.cmu.edu/
> Ah, I see it doesn't mention the subscribe addresses (changelog-request@...)

Well, my meta-point was that I'm one of the longest-time non-CMU coda
users (since 1997 when Peter showed me coda at a Glomo PI meeting?), and
if I didn't just know, that says something.

>>   sending a note to codalist whenever anything signficant has been
>>   committed to cvs
>
> It is sometimes hard to define significant, if I have a change that
> improves sftp download bandwidth over high latency links by several
> orders of magnitude. Is that important? For some people it definitely
> would be.

Given the traffic on codalist, I can't imagine anyone would object to
knowing more abotu what's changing.  changing to automake is
significant.  Changing the API of rpc2 is significant.  gcodacon is
significant.

> But on the other hand, maybe a simple change goes in, which I've tested
> between a development client and server without problems, but after the
> change was committed it turns out that it introduced an RVM
> incompatibility when you try to upgrade a client running the latest
> release. Sometimes it is simply unclear whether a change was significant.

true.  I suggest erring on the side of sending the note.  I really doubt
you'll be getting any "stop sending so much mail" complaints.  Even with
all my ranting I don't get such hate mail :-)

>>   not cutting an rc the day after stuff that might break long-working
>>   functionality goes in to cvs
>> 
>>   if the anoncvs people can check out from isn't the real repo (or a
>>   copy of it for security reasons), explain what's going on.
>
> The anoncvs server is exporting from a repository in Coda. However the
> read/write CVS repository is stored in AFS. Once every 15 minutes or so
> the Coda snapshot is updated.

OK, that's cool - no objections whatsoever.  I was wondering if there
was some git or hg or other repo-du-jour that had the real work was
being occasionally synced into cvs.  15 minutes is way fast enough

> There are several reasons why we do not export directly from AFS.

no problems - I am not asking for the real repo to be on the net, just
that anoncvs in a reasonably timely manner reflect the real state of the
dev tree.  15 minutes is well into reasonably timely - 4 hours would be ok.

> Now although the CVS repository in AFS is the canonical version that we
> check out from when a new release is made, I do all of my development in
> a git repository. I bounce branches that I work on back and forth
> between my desktop, laptop, machine at home and whatever VM of the day I
> am working with (f.i. freebsd etc).
>
> Git is very good at branching and merging, CVS is not. So by the time I
> am happy with some development branch, I use 'git rebase' to create a
> linear history on top of what is at that point the latest CVS version
> and then run a script that walks through the list of commits that are
> not in 'master' and applies them to CVS. So that hopefully explains for
> a part the occasional patch-storms.

sure, but you really should push stuff to cvs and let the cvs coda users
test before release.

>> I wonder if this is why my machine was not happily communicating with
>> testserver.
>
> Possibly, although most systems seem to use the identical errno values,
> considering how 'well' Coda has worked without doing any translation.
> The error numbers that were moved around were those that do not exist on
> typical UNIX system (EINCONS - conflict detected).

maybe something else.  it was flaky again today.  BTW, I don't get why
my machine was even trying to talk to testserver - I reinited to avoid
that!