gEDA-dev: Version numbering

[Peter TB Brett]

On Friday 29 June 2007 05:38:40 Dan McMahill wrote:

> > I also thought about highly encourging that development snapshots would
> > never end up in a binary distribution and that only stable releases
> > would get packaged up (in whatever distribution be it debian, netbsd,
> > fedora etc...).  However, I'm not about to attempt to enforce that.
>
> I don't mind making the switch but I worry that what will happen is
> we'll see rare "stable releases" and we'll end up always saying "try a
> development release" or "get whats in git".  And I really don't want to
> bounce back and forth.

The idea of the stable branch as originally suggested by me was mostly to make 
sure that people using distributions where Guile 1.8 was not available were 
not left out in cold w.r.t. to major flaws & crash bugs until they upgrade.

There is a rapid accumulation of of changes happening in the unstable branch.  
In particular, there are several minor bugs & security holes fixed by my 
component library work which can't be backported without making stable look 
pretty much the same as unstable!  It's _really_ important for such a 
(relatively) small project that the features being put into unstable get 
_used_.  We don't have the manpower or infrastructure to do a proper QA 
within the project's active developers, and user feedback is _very_ important 
to us.

I would therefore support encouraging people not to package unstable if, and 
only if, the unstable branch gets stabilised and released _frequently_ (say 
~3 months).  Nevertheless, development snapshots would still be a good thing 
for people who, for instance, don't like using git but want to test unstable 
for us.

One of the nice things about the x.y.z numbering scheme where y is odd for 
unstable and even for stable[1] is that the unstable version is always an 
increment in away from the stable version.  This seems nice for package 
maintainers.

I won't deny that I absolutely detest dated releases (humans aren't good at 
parsing/comparing unbroken numeric strings of more than four characters, and 
they give no indication of stability or maturity) and I would be more than 
happy to see the back of them as far as gaf is concerned.

Finally, this sort of debate was always bound to happen at some point, and I'm 
pretty sure that all projects have these problems (the Linux kernel has had 
them several times!)

Thanks,

Peter

[1] x: major version number
    y: branch number
    z: release number

-- 
Peter Brett

Electronic Systems Engineer
Integral Informatics Ltd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.seul.org/pipermail/geda-dev/attachments/20070630/7b1faae3/attachment.pgp