Re: [XForms] Version numbers and next release - please read!

[saulgoode]

Quoting Jens Thoms Toerring <address@hidden>:

>    In the beginning there were version and revision numbers
> (or, at least, that's what I guess were the original inten-
> tions). For minor bug fixes also a fix-level would be used
> but that wasn't anything that was "advertised" by the li-
> brary.

What you describe as "version.revision.fixlevel" would be considered  
"major.minor.revision" under the guidelines presented by GNU for  
versioning of projects. For this post, I will use your terminology.

Some of GNU's recommendations include:

  The version number should be incremented when the API changes
  in a backwards incompatible way.

  The revision number should be changed when new features are
  added. The API can have new functionality added, but must
  maintain backwards compatibility. It is common in GNU
  projects to employ even-numbered revisions for stable
  releases and perform development on branches that use
  odd-numbered revisions (the version numbers would be the
  same).

  The fixlevel number gets incremented whenever a release occurs
  after the code has been changed. For stable branches, code
  changes should be limited to bug fixes -- non-trivial features
  should not be added. For the development branch, new features
  can (of course) be added.

This approach is nice because client software needn't worry about  
fixlevel versioning, and rarely should be concerned with revision  
changes (unless they are depending upon the new features. It is also  
nice for developers because the same functions (or build macros) can  
be used for validating versioning for both the development and stable  
branches, facilitating distribution and testing of the development  
releases.

The GNU approach has the disadvantage that regular end-users are often  
unaware of the significance of the parity of the revision number. This  
should not be such a problem for XForms because its "end users" should  
mostly consist of developers and distro packagers for the most part  
familiar with versioning issues.

> ...   What's the problem with that? Using functions supplied
> by the library (fl_library_version()) one can only deter-
> mine the version and revision number, but not the fix-level
> (i.e. 0, 91, 92, 93 etc.), so 1.0, 1.0.91, up to 1.0.93 all
> are reported as the 1.0 version. ... now versions which aren't  
> compatible are indistinguishable by using functions
> in XForms.

In my opinion, this problem had more to do with the addition of new  
features in fixlevel releases than with the versioning scheme itself.  
The functionality currently provided by fl_library_version() should be  
sufficient -- clients shouldn't ever need to base their behavior on  
fixlevel changes.

>    While I can't undo my mistakes from the past I am considering
> to go back to a somwehat "saner" versioning scheme, i.e. having
> only version and revision numbers making a real difference and
> using fix-level numbers for only what they were meant for, i.e.
> designating bug-fix releases without any other changes that might
> introduce any kind of incompatibilities (that includes introduc-
> tion of new functions and whatsoever).

Other than the even/odd parity significance of the revision number  
(and a terminology difference), what you propose would seem in keeping  
with the GNU guidelines.

>    But: to do that we would have to finally switch to a 1.1
> version, Now, I always had somehow considered "version 1.1"
> to be something that would address all problems ever expe-
> rienced with XForms;-) But perhaps that's expecting a bit too
> much and switching to a more useful version numbering scheme
> might be more beneficial than waiting for a mythical perfect
> version we then would proudly call 1.1.

Well, if you choose to switch over to the GNU guidelines, you could  
release 1.1 as a development branch (though for this initial case, one  
focusing mainly on bug fixing), and release a 1.2 stable branch when  
it's ready (hopefully not too long afterward).