[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: saulgoode
Subject: Re: [XForms] Version numbers and next release - please read!
Date: Sun, 12 Dec 2010 05:29:35 -0500
User-agent: Internet Messaging Program (IMP) H3 (4.3.9)

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-

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

  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).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]