Re: [Gretl-devel] versioning
(To readers other than Johannes: sorry for the element of
repetition, but I wanted to bring Johannes in on this topic.)
(To Johannes: for more context, please see the thread beginning with
http://lists.wfu.edu/pipermail/gretl-devel/2015-September/005945.html
)
Let me be as clear as I can on the proposed change in gretl
versioning, hoping that Dirk and Johannes can tell us if this would
be a problem for Debian or Fedora.
Background: the primary source for all gretl version information is
the file lib/src/version.h. This contains 4 relevant lines, which
currently read as follows:
#define LIBGRETL_CURRENT 14
#define LIBGRETL_REVISION 0
#define LIBGRETL_AGE 0
#define GRETL_VERSION "1.10.2"
The first 3 lines pertain to the gretl library, and are basically
libtool-speak for SemVer's MAJOR, MINOR and PATCH. These lines
govern the name of the gretl shared library, currently
libgretl-1.0.so.14.0.0, and nothing else.
The GRETL_VERSION string governs what appears in the logos for the
command line programs, gretlcli and gretlmpi, and under /Help/About
in the GUI program. It also governs the name of the released source
package, currently gretl-1.10.2.tar.xz. In addition the digits in
this string are used to form the built-in variable named $version
according to the rule
$version = 10000*M + 100*N + P
for release M.N.P. This integer variable is really only of interest
to writers of function packages for gretl; it is not displayed
anywhere.
Proposal: move to <year><letter> for GRETL_VERSION while maintaining
the current set-up for the library version (but be more rigorous in
applying the SemVer rules for the latter).
Example: suppose we make another release this year. GRETL_VERSION
would become "2015d" (since we'e already made three releases this
year). The source package would be named gretl-2015d.tar.xz. The
programs would display "2015d" in logos and /Help/About. As for the
library,
* If we just fix bugs (compatibly), we go to 14.0.1
* If we add functionality without breaking compatibility: 14.1.0
* If we break API compatibility: 15.0.0
In addition the built-in $version would be redefined as 10*<year> +
lexical order of <letter>, giving 20154.
As I said above, the $version variable is primarily of interest to
function writers, but of course if anyone else wants to use it for
their own purposes they're welcome to do so; we guarantee that it's
defined such that it increases monotonically by release.
Allin Cottrell