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 [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
