On Sun, Aug 12, 2007 at 07:35:24AM -0400, Greg Troxel wrote:
> Yes, that looks like a better plan.

> Please just set version to e.g rpc2-2.6.90 (for beta), or if you must
> rpc-2.7rc1, so that packaging systems that are used to those conventions
> don't have to learn yet another flavor-of-the-month in naming/sorting.

Yeah, naming is a bit of a mess, I spent some time this weekend to look
at how different packaging systems do pre-release and development
snapshot versioning and there seem to be different popular schemes, some
I like better than others. 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

In either case, important bugfix releases should contain the minimal
necessary change to resolve the identified problem, if a more involved
rewrite would make the fix/code cleaner that should just go into
development.


> <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.

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.

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

    'Version numbering madness'

> I realize you don't want packaging systems to be actually updated -
> that's the point, but the packaging systems need testing, and IMHO the
> way to do that is to do the update to the rc version and not commit it.

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.

> 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.

> 		"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.

> Also I'd suggest:
> 
>   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@...)

>   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.

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.

>   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.

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

    - Even just the read-only export is an nice test case for Coda.
    - We had stability issues with the OpenAFS kernel module on our
      webserver (maybe fixed now, honestly don't know since we don't run
      AFS on the webserver anymore :). The actual synchronization runs
      on another machine that has both Coda and AFS.
    - Authentication issues, the AFS repository is ACL protected, the
      Coda copy can be accessed by System:Anyuser.

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.

> 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).

Jan