Re: [Gretl-devel] versioning
On 16/09/15 22:47, Allin Cottrell wrote:
(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.
Hi all,
I don't have any issue with the proposed versioning scheme. I didn't see
any problems with either the numerical or numerical+alphabetical
versioning scheme in rpmdev-vercmp.
It seems both work for rpm/dnf and since all versions including a year
are considerably bigger than the current version, I don't see any issue
with upgrade paths.
Since we are at it, what about some refresh to the whole gretl brand. I
mean, we probably are all not so much into graphics design, but I think
some updates to the icons and logos would probably also send out
positive signals.
Cheers,
Johannes
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