[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Arbitrary version names

From: David Allouche
Subject: Re: [Gnu-arch-users] Arbitrary version names
Date: Sat, 28 Aug 2004 13:55:06 +0200

On Tue, 2004-08-17 at 12:13 -0700, Tom Lord wrote:
> Now, to your specific example.    I gather that you want a
> "sub-version branch" added to the namespace.  So that instead of:
>       category[--branch]--version--revision
> names are:
>       category[--branch]--version[--version-branch]--revision
> Quite honestly, I think I've changed my mind.   I *do* like that.

I'm very surprised that nobody made any noise before, since you are
accepting to make a significant change to the structure of the
namespace... Let me do some.

== Naming ==

I already hate "version-branch". It's awkyard and confusing.

What about:

      * "subversion". It's not like that is already the name of anything
        useful :-P
      * "phase". Or whatever the industry name for alpha/beta/rc
      * "release".
      * "spoon".
      * "powersaw".
      * "nail".

== Ordering ==

Currently all namespace items below branch are totally ordered. I
thinking that is a useful property.

Different category--branch have no natural relative ordering. Using
lexical ordering is useful but arbitrary. On the other hand, the fact
that "tla get" can accept a fully-qualified branch and and pick the
"latest" revision relies on a natural ordering.

What will be the ordering rule for version-branch? Lexical?

== Nameless ==

How the nameless version-branch, in contrast to the whole version, is
going to be reffered to in functions like abrowse and archive-mirror?

We already have trouble with nameless branches, do we really want more
of it?

== Relation to aliases ==

If you can address all of this satisfactorily, I will be very happy. But
I believe we can satisfy the users almost as well with public per-
archive aliases.

So, for example, linux--arm--2.6.7--arm1 would be an alias for
linux--arm-arm1--2.6.7. That would effectively dodge all the issues
involved in modifying the namespace and would give the user the desired

                                                            -- ddaa

reply via email to

[Prev in Thread] Current Thread [Next in Thread]