Re: gEDA-dev: gEDA/gaf stable version 1.0.1-20070626 released!

[Dan McMahill <dan@xxxxxxxxxxxx>]

Ales Hvezda wrote:
> Hi Hamish, Charles, and all,
> 
> [snip]
>> How do you envisage version numbers to work in the future?
> 
> That's a very good question that several people have asked.  
> 
> I see a few possibilities:
> 
> 1) Go back to just the date version number (20070626).  
>    Advantage: No changes in numbering required for binary packages.
>    Disadvantage: Can't tell the difference between stable releases
>                  and development snapshots.
> 
> 2) Just expose the dotted version like 1.0.1.  Where 1.even#.release#
>    is a stable snapshot and 1.odd#.release# is a development snapshot.
>    Advantage: It is want everybody is used to.  
>    Disadvantage: No relationship between version and date.
> 
> 3) Have a mix like: 1.0.1-20070626.  
>    Advantage: All the information is there.
>    Disadvantage: Kind of a mouthfull.
> 
> 4) ???
> 
> In all of the cases, I will maintain the date version internally and
> the appropriate version type will be shown to the user (including the
> tarball filenames; something I didn't get around to changing in the
> release).
> 
> 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.
> 
> Please comment.

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.  There are a number of tools which may try to 
compare versions in pkgsrc and probably other packaging systems.  It 
causes a handful of headaches to try and distinguish between 
gschem-20070101 and gschem-1.0.  Which is newer?  Is switching an 
upgrade or a downgrade?  What if there is a security hole in one version 
so we want an entry in a vulnerability file that says foo<=1.3 is 
vulnerable?

For Icarus verilog what I did was create both a verilog-current package 
that uses the yyyymmdd versioning scheme and a verilog pacakge that used 
the major.minor.tiny versioning.   Thats manageable for Icarus verilog 
because I rarely have issues building it (any patches tend to be minor 
and anything which needs configuring in the build system is already 
supported by the build system in a standard way).  Also the fact that 
Icarus verilog is a single distfile and single package makes it easy. 
I'll note that in that case, there are real new features in the later 
development snapshots that just aren't present in the stable releases so 
there has been value in packaging them.

When gnucap-0.34 was way out of date the guidance I was given was to 
just update to a development snapshot and now I'm being asked to go back 
to 0.35.  I'll probably move back to 0.35 but will not be doing more 
development snapshot packages unless it gets a new name (gnucap-current 
or gnucap-devel).  The mix and match of versioning is just not good.

Currently gaf is split into quite a few packages:  geda-utils, libgeda, 
geda-docs, geda-symbols, geda-examples, gschem, gattrib, gnetlist.    So 
thats 8 packages which all need updating in lock step.  I'm really not 
excited about turning that into 16 (libgeda, libgeda-current, gschem, 
gschem-current, etc).  So I guess in the gaf case we're back to my 
original concern which is that the stable releases will turn into the 
"stale" releases.

Don't underestimate the amount of work needed to maintain a stable branch.

-Dan



_______________________________________________
geda-dev mailing list
geda-dev@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev