Re: [Gnu-arch-users] What are version numbers?

[Zack Brown]

On Wed, Sep 10, 2003 at 03:03:40PM -0700, Tom Lord wrote:
> 
>     > From: Zack Brown <address@hidden>
> 
>     > It's starting to make sense now. It seems like you really do intend
>     > there to be a clear relationship between the project version number, and
>     > the tla version number. It's just that the tla version number refers to
>     > a whole sweep of project version numbers. So tla version 1.0 would
>     > contain project versions 1.0.1, 1.0.2, etc.
> 
> 
> Yes.

OK. I'm pretty sure I've got it now. In that case, I have two
suggestions:

1) the nomenclature "version" is a little misleading. I think I would
have had a much easier time understanding this feature if it were called
"series". I suggest converting the 'version' nomenclature to 'series' or
"version series".

2) the convention "category--branch--version" doesn't indicate the most
likely relationship between the three elements. As you've said, it's much
more likely that 'version' will refer to a version of the category, and
should thus be bound more tightly to 'category' than to 'branch'. On the
other hand, nothing is lost by putting 'branch' at the end of that trio,
because a branch may be split off under any circumstances.

Another way of looking at it is in terms of what changes most often. The
category name is only changed when you go to work on a completely different
project. So that is the most stable element of the three. The version is
only changed for a new series of releases, while there can be many branches
within a given series. Ordering the three elements in terms of least-to-most
volatile will mirror current versioning schemes (e.g. in kernel 2.6.0, the 2
is least volatile as the major number, the 6 is more volatile as the series
number, and the 0 will be incremented most often, as the patch number.).
This also seems to be a convention followed elsewhere in tla.

So I suggest converting the naming convention from "category--branch--version"
to "category--version--branch". And if you accept my first suggestion as well,
it would become "category--series--branch".

I think those suggestions taken together preserve the functionality of tla,
while adding some good clarity and intuitiveness (downward scalability)
to the structure.

Be well,
Zack

> 
> Something else that comes into play here, which I've used in the past
> but don't happen to recently, are the `--seal' and `--fix' options to
> commit.   So you could, if you wanted, have the convention that:
> 
> 
>       project--mainline--X.Y--version-0
> 
> (created with --seal) corresponds to release:
> 
>       project-X.Y
> 
> and:
> 
>       project--mainline--X.Y--versionfix-Z
> 
> (created with --fix) corresponds to release:
> 
>       project-X.Y.Z
> 
> 
> But there's way too much flexability in the system to require that
> isomorphism.   You can use config names to map from release names to
> versions.   You can use N-component version numbers.  You can throw
> tags into the mix...
> 
> It's a cataloging system, as in what libraries use (but sans the
> dictionary of pre-defined terms which, currently, would at most
> contain the keyword "devo" when used as a branch label).  As a
> cataloging system -- it just goes half-way from "unstructured" to
> "cataloged", relying on a cultural context to evolve and meet it
> halfway.
> 
> Ask me about how I'd do a GNU/linux distribution using arch sometime.
> (And, for a most-likely-dissenting opinion, ask asuffield.)   The
> issue I mean is: how to make thousands of separately developed
> packages managable en-masse with the smallest amount of labor and the
> largest amount of power.
> 
> -t
> 
> 

-- 
Zack Brown