Re: GEP-4 : Versioning and branching rules proposal

[Thomas Vander Stichele <thomas apestaart org>]

Hi,

some questions/remarks from my point of view ...

> Users would continually downloaded
> the new packages, but for nothing. Lots of hassle and for what?

I agree that this would be a problem, I don't see an easy way to solve it 
though.

Let's take an other example - metacity is up to version 2.4.0 - do we let 
it "downgrade" because of this and cause massive confusion when gnome 2.4 
is out ?

> 	* There are quite a few packages in the platform that aren't
> really specific to GNOME. Should they have to conform to these rules.
> If not, where do we draw the line of modules that should and modules
> that shouldn't. Could we have a compromise set of rules for these
> modules. E.g. that they tag the module after every release.

I'd like to know what these rules would mean for fifth-toe stuff.  From 
the POV of GStreamer, it will be some time before we go 1.0 at all.  
Jumping to 2.0 just because we're going to be used by GNOME is a bit silly 
to us.

On an unrelated note, we also do something special with our version 
numbers which solves a few problems we used to have, which I'm throwing 
out for consideration here.

Here's the scheme :
* all official versions have major.minor.micro versioning
  with fairly common rules 
  - micro changes are for bug fixes, minor 
    features, (mostly) API-compatible changes
  - minor changes are for big API changes, major reworkings, ...
  - major changes are for screwing up users in a really bad way ;)

* Beside that, we also use a nano number.  
  - During the whole of our
  development period, this number is set to 1.  What this means is
  that if you see ANY GStreamer package (tarball, rpm, maybe even deb)
  which is marked x.y.z.1, it's a CVS release.  Also, if you get user
  feedback for bugs, it's nice to know that he's using a CVS release
  (for some reason lots of people always end up using GStreamer CVS
   and it used to cause us a lot of headache to figure that out).
  - When we're about to make a release, we make a release branch.
    HEAD gets new major:minor:micro numbers (for the next release),
    and keeps nano at 1.  The release branch only gets bug fixes and
    so on for the release.  Then we start doing prereleases of that
    branch, and increment the nano, starting with 2.

To recap:
  - releases without nano numbers are "officially supported" releases.
  - tarballs/packages with nano 1 are "CVS snapshots".  (The RPM's
    made from this have the build date and time as their release number)
  - tarballs/packages with nano > 1 are pre-releases of the next release.

What this solves for us:
  - we avoid all the mess with naming packages -rc or -beta and so on.
  - we can easily generate CVS snapshots which are clearly marked
    (both in packages, AND in use) as CVS
  - people don't generate their own "official" version from CVS, or
    worse, release them (We've had one rhythmbox guy release his custom
    gstreamer RPM because he wanted to make rhythmbox RPMs, which could
    have been hell for us to maintain/support/...)

Now, some of you might not like the way we abuse the versioning system; 
it's kind of a mixed approach.
I'm just saying that something like this might be worth considering 
somehow, but I'm also saying, that this approach has helped us well in the 
last year, and GStreamer as a project would probably like to continue 
doing this.  I'm not sure if this is a problem with the proposed 
versioning scheme ?

> 	* How about versions like '2.2.0-rc5'. I've never used them,
> but it does strike me that they are more readable and readily
> identifiable.

Please don't ;) I'd like it (if you all agree) if a rule to the GEP would 
be added that there shall be no -rc, -alpha, -beta, or other alphabetic 
versioning.  It's really messy for making packages (most packaging systems 
use alphanumeric comparison, and are then forced to use Epochs or 
something similar, which are even worse).
Also, in most cases, the -rc package ends up using the exact same version 
number internally as the final release, so if you get bug reports, how can 
you tell the difference ?

Thomas

-- 

The Dave/Dina Project : future TV today ! - http://davedina.apestaart.org/
<-*-                      -*->
Is there a voice unkind
in the back of your mind
saying "maybe you didn't know him at all"
<-*- thomas apestaart org -*->
URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/