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

[Stephen J. Turnbull]

>>>>> "Bruce" == Bruce Stephens <address@hidden> writes:

    Bruce> Zack Brown <address@hidden> writes:

    Bruce> [...]

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

    Bruce> That's a nice clear description.

Clear for what it describes, but incomplete.  The problem with the
nomenclature may be insoluble, because it's clearly desirable to have
a unique serialization of {category, {branch, version}} (ie, the outer
set is effectively an ordered pair, while the inner set is unordered)
for naming (ie, in tla commands), but there are definitely situations
where one or the other of the two possible serializations make more
sense.

For example, in XEmacs I would probably have (with a 500MB CVS
repository and temporary space constraints, I haven't had the nerve to
make an arch project for it yet) a structure something like this,
where the branches are quite long-lived:

categories    branches        versions
----------    --------        --------
xemacs-21-1   release         ...
                              14
xemacs-21-2   devo            0        # tag of "20.4"
                              ...
                              47
              ...
xemacs-21-4   release         0        # tag of xemacs-21-2--devo--47
                              ...
                              14
xemacs-21-5   devo            0        # tag of xemacs-21-2--devo--47
                              ...
                              9
                              ...
                              14
                              15
              carbon          9.0      # tag of xemacs-21-5--devo--9
                              9.1      # merge of contributed code
                              15.0     # merge of mainline improvements
                              ...      # in-progress patch levels
              xft             14.0     # tag of xemacs-21-5--devo--14
                              ...      # in-progress patch levels
              mode-locale     15.0     # tag of xemacs-21-5--devo--15
                              ...      # in-progress patch levels

[*] XEmacs uses an odd-even alternation, for hysterical raisins
switched devo from even to odd after 21.2.

The idea would be that the "major number" of the arch "version" would
be kept in sync with the mainline as the branch code was updated,
while the "minor number" would indicate milestones reached in branch
development.  So really, although versions are somewhat constrained by
cross-branch considerations, they primarily express "on-branch"
progress.

Note that although the semantics would be preserved by
category--version--branch, the sorting (eg, by tla browse) would not.
But that's clearly wrong most of the time in this context, although
surely there will be use cases where I'd like to see the "cross-
fertilization" different branches in "historical context" (and then,
I'd want the category--version--branch sort priority).

So I think the right thing to do is to create browsing tools that
parse the category as hierarchically superior to both branch and
version, and allow the user to conveniently determine both default and
per instance priority of branch and version.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.