2:07 p.m.
Thanks for Artur for putting this back on the agenda.
http://lists.wfu.edu/pipermail/gretl-devel/2015-September/005937.html
I suggest we discuss the issue a bit more fully -- consider the merits
of the proposal and not just the technicalities -- and make a
decision.
The proposal is that we move to a version string of the form
<year><sequential release>, the cleanest variant of this being (IMO)
2015a, 2015b, ...
As I see it it the pros and cons are roughly as follows:
Pro:
* Coming up with a version identifier for each release becomes purely
algorithmic: no need (or scope) for discussion.
* Version identifiers become clearly informative. If someone tells you
they're running gretl YYYYx you know immediately how old it is without
having to look up the change log.
* It reflects the fact that gretl development has been for many years
a more or less continuous process. From time to time the changes
between versions have been relatively major (new "genr"
implementation, new command "tokenizer", introduction of GMM, etc.)
but to date we have never signalled that by a change in the "major"
version number, which is therefore uninformative. We've changed the
"minor" version from time to time, but without any clear principle.
Con:
* We'd be out of line with most free-software projects, which tend
(for whatever historical reason) to the use the M.N.P versioning
idiom.
* We would lose the ability to signal a major, backward-incompatible
change with a major-version bump. (But it's not clear that we'd ever
actually want to do that.)
* It will be a certain amount of bother to make the change, and we'd
probably want to check that it won't be too bothersome for
"downstream" packagers of gretl for Linux, particularly if we go to
<year><letter> (which I prefer) rather than <year>.<number>.
Personally I quite like the proposal, and I'd be prepared to do the
work needed to implement it if we decide that way.
It would obviously be easy to retrospectively label all releases to
date using the proposed scheme (e.g. in the change log, where we
should keep the old version IDs too, for reference). And as Sven has
said, we could easily translate the proposed idiom to a single integer
that preserves order. At present we have
$version = 10000*M + 1000*N + P
so 1.10.2 -> 11002
Just say our next release were "2015d": in that case we could
define
$version = 10*year + alpha_order(letter)
so 2015d -> 20154
(This would get messed up if there were more than 9 releases in a
given year, but I think we can rule that out.)
Allin
6:03 p.m.
Am 15.09.2015 um 16:07 schrieb Allin Cottrell:
Pro:
* Version identifiers become clearly informative. If someone tells you
they're running gretl YYYYx you know immediately how old it is without
having to look up the change log.
Not compelling, but also nice.
* It reflects the fact that gretl development has been for many years a
more or less continuous process. <...>but to date we have
never signalled that by a change in the "major" version number, which is
therefore uninformative.
IMHO this is the major advantage.
Con:
* We'd be out of line with most free-software projects, which tend (for
whatever historical reason) to the use the M.N.P versioning idiom.
If we were at M==38 or M==40 like Thunderbird or Firefox the MNP system
would be less of a problem...
* We would lose the ability to signal a major, backward-incompatible
change with a major-version bump. (But it's not clear that we'd ever
actually want to do that.)
Right (to the statement in parenthesis), see the thing on "continuous"
process.
It would obviously be easy to retrospectively label all releases to date
using the proposed scheme (e.g. in the change log, where we should keep
the old version IDs too, for reference).
But why do that and "fake" history?
cheers,
sven
6:42 p.m.
On Tue, 15 Sep 2015, Allin Cottrell wrote:
Thanks for Artur for putting this back on the agenda.
http://lists.wfu.edu/pipermail/gretl-devel/2015-September/005937.html
I suggest we discuss the issue a bit more fully -- consider the merits of the
proposal and not just the technicalities -- and make a decision.
The proposal is that we move to a version string of the form
<year><sequential release>, the cleanest variant of this being (IMO) 2015a,
2015b, ...
As I see it it the pros and cons are roughly as follows:
Pro:
* Coming up with a version identifier for each release becomes purely
algorithmic: no need (or scope) for discussion.
* Version identifiers become clearly informative. If someone tells you
they're running gretl YYYYx you know immediately how old it is without having
to look up the change log.
* It reflects the fact that gretl development has been for many years a more
or less continuous process. From time to time the changes between versions
have been relatively major (new "genr" implementation, new command
"tokenizer", introduction of GMM, etc.) but to date we have never signalled
that by a change in the "major" version number, which is therefore
uninformative. We've changed the "minor" version from time to time, but
without any clear principle.
True. Let me add: as the project has become more and more stable, releases
have become far less frequent than they used to be (see attached chart).
Something like "2016c" sounds more informative than (say) "1.10.5",
without sounding as funny as "2001q".
Con:
* We'd be out of line with most free-software projects, which tend (for
whatever historical reason) to the use the M.N.P versioning idiom.
True, but that's increasingly being called into question, the Linux kernel
being a prime example.
* We would lose the ability to signal a major, backward-incompatible
change
with a major-version bump. (But it's not clear that we'd ever actually want
to do that.)
I wouldn't rule this out, at some point in the future. But I guess
that with major, backward-incompatible change version numbering would be
the least of our worries!
* It will be a certain amount of bother to make the change, and
we'd probably
want to check that it won't be too bothersome for "downstream" packagers of
gretl for Linux, particularly if we go to <year><letter> (which I prefer)
rather than <year>.<number>.
I guess thet the foremost authority on this would be Dirk (whom I'm
putting in cc).
Personally I quite like the proposal, and I'd be prepared to do
the work
needed to implement it if we decide that way.
It would obviously be easy to retrospectively label all releases to date
using the proposed scheme (e.g. in the change log, where we should keep the
old version IDs too, for reference). And as Sven has said, we could easily
translate the proposed idiom to a single integer that preserves order. At
present we have
$version = 10000*M + 1000*N + P
so 1.10.2 -> 11002
Just say our next release were "2015d": in that case we could
define
$version = 10*year + alpha_order(letter)
so 2015d -> 20154
(This would get messed up if there were more than 9 releases in a given year,
but I think we can rule that out.)
Alternativey, we could use the convention
$version = 1000*(year-2000) + alpha_order(letter)
so 2015d becomes 15004 but 2015k (if ever necessary) would be 15011.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
9:06 a.m.
Hi guys,
Real brief, am conference traveling over in London, ...
On 15 September 2015 at 20:42, Riccardo (Jack) Lucchetti wrote:
| On Tue, 15 Sep 2015, Allin Cottrell wrote:
|
| > Thanks for Artur for putting this back on the agenda.
| >
| > http://lists.wfu.edu/pipermail/gretl-devel/2015-September/005937.html
| >
| > I suggest we discuss the issue a bit more fully -- consider the merits of the
| > proposal and not just the technicalities -- and make a decision.
| >
| > The proposal is that we move to a version string of the form
| > <year><sequential release>, the cleanest variant of this being (IMO)
2015a,
| > 2015b, ...
| >
| > As I see it it the pros and cons are roughly as follows:
| >
| > Pro:
| >
| > * Coming up with a version identifier for each release becomes purely
| > algorithmic: no need (or scope) for discussion.
| >
| > * Version identifiers become clearly informative. If someone tells you
| > they're running gretl YYYYx you know immediately how old it is without having
| > to look up the change log.
| >
| > * It reflects the fact that gretl development has been for many years a more
| > or less continuous process. From time to time the changes between versions
| > have been relatively major (new "genr" implementation, new command
| > "tokenizer", introduction of GMM, etc.) but to date we have never
signalled
| > that by a change in the "major" version number, which is therefore
| > uninformative. We've changed the "minor" version from time to time,
but
| > without any clear principle.
|
| True. Let me add: as the project has become more and more stable, releases
| have become far less frequent than they used to be (see attached chart).
| Something like "2016c" sounds more informative than (say) "1.10.5",
| without sounding as funny as "2001q".
|
| > Con:
| >
| > * We'd be out of line with most free-software projects, which tend (for
| > whatever historical reason) to the use the M.N.P versioning idiom.
|
| True, but that's increasingly being called into question, the Linux kernel
| being a prime example.
|
| > * We would lose the ability to signal a major, backward-incompatible change
| > with a major-version bump. (But it's not clear that we'd ever actually want
| > to do that.)
|
| I wouldn't rule this out, at some point in the future. But I guess
| that with major, backward-incompatible change version numbering would be
| the least of our worries!
|
| > * It will be a certain amount of bother to make the change, and we'd probably
| > want to check that it won't be too bothersome for "downstream"
packagers of
| > gretl for Linux, particularly if we go to <year><letter> (which I
prefer)
| > rather than <year>.<number>.
|
| I guess thet the foremost authority on this would be Dirk (whom I'm
| putting in cc).
|
| > Personally I quite like the proposal, and I'd be prepared to do the work
| > needed to implement it if we decide that way.
| >
| > It would obviously be easy to retrospectively label all releases to date
| > using the proposed scheme (e.g. in the change log, where we should keep the
| > old version IDs too, for reference). And as Sven has said, we could easily
| > translate the proposed idiom to a single integer that preserves order. At
| > present we have
| >
| > $version = 10000*M + 1000*N + P
| > so 1.10.2 -> 11002
That is being used elsewhere ... but only internally. Here is what our Rcpp
does:
#define Rcpp_Version(v,p,s) (((v) * 65536) + ((p) * 256) + (s))
#define RcppDevVersion(maj, min, rev, dev) (((maj)*1000000) + ((min)*10000) +
((rev)*100) + (dev))
// the currently released version
#define RCPP_VERSION Rcpp_Version(0,12,1)
// the current source snapshot
#define RCPP_DEV_VERSION RcppDevVersion(0,12,1,0)
But version numbers are for humans first. I urge you to reconsider and do
something like
2015.09-n
as eg ESS (Emacs mode for R) does. Or just keep with 1.2.3 -- I would
counter the "it is under attack". Google 'semantic versioning', it is
very
much alive and used. I still prefer it.
| > Just say our next release were "2015d": in that case we could
| > define
| >
| > $version = 10*year + alpha_order(letter)
| > so 2015d -> 20154
| >
| > (This would get messed up if there were more than 9 releases in a given year,
| > but I think we can rule that out.)
|
| Alternativey, we could use the convention
|
| $version = 1000*(year-2000) + alpha_order(letter)
|
| so 2015d becomes 15004 but 2015k (if ever necessary) would be 15011.
I find that mostly unreadable and would use it at most internally.
Cheers, Dirk
|
| -------------------------------------------------------
| Riccardo (Jack) Lucchetti
| Dipartimento di Scienze Economiche e Sociali (DiSES)
|
| Università Politecnica delle Marche
| (formerly known as Università di Ancona)
|
| r.lucchetti(a)univpm.it
| http://www2.econ.univpm.it/servizi/hpp/lucchetti
| -------------------------------------------------------
| [DELETED ATTACHMENT releases.png, PNG image]
--
http://dirk.eddelbuettel.com | @eddelbuettel | edd(a)debian.org
3:30 p.m.
On Wed, 16 Sep 2015, Dirk Eddelbuettel wrote:
[...]
[V]ersion numbers are for humans first. I urge you to reconsider and
do something like
2015.09-n
as eg ESS (Emacs mode for R) does. Or just keep with 1.2.3 -- I
would counter the "it is under attack". Google 'semantic
versioning', it is very much alive and used. I still prefer it.
On semantic versioning, see http://semver.org , where this approach is
defined and advocated. I think this makes a lot of sense for libraries
upon which other software is dependent. Now in fact we have been "sort
of" using semantic versioning for the libgretl library for some time.
The current libgretl is
libgretl-1.0.so.14.0.0
(MAJOR=14, MINOR and PATCH=0). What we've done for the last several
releases is increase the MAJOR number each time, leaving MINOR and
PATCH at zero. This reflects the fact that (almost) every release has
brought some backward-incompatible change in the libgretl API. That in
turn reflects the fact that, as a practical matter, we don't have to
worry much about maintaining API compatibility since, to our
knowledge, there's no other public free software project that depends
on libgretl. (And we've never released the programs and the library
independently, but always as a package.)
I think we could maintain SemVer for the gretl library (and apply it
more rigorously[*]) while switching to <year><letter> for gretl the
program. It seems to me that SemVer doesn't really apply to end-user
programs (nor to the Linux kernel, as Jack mentioned). What we've done
to date with the gretl X.Y.Z version numbers sorta looks like semantic
versioning but the resemblance is superficial, and the numbers are
not meaningful to users -- and as Dirk says, "version numbers are for
humans first."
[*] For example, in the 1.10.1 release we just fixed a bug, so if we
were following SemVer accurately the library version should have gone
from 12.0.0 to 12.0.1, not 13.0.0.
Allin
8:47 p.m.
(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
11:57 a.m.
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
8:16 a.m.
Am 17.09.2015 um 13:57 schrieb Johannes Lips:
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.
Yes that would probably be good, and I think somebody (Henrique?) at
some stage tried to do something about the icons, but maybe that was
just porting them to svg or something.
Also, Allin and Jack have pronounced themselves quite conservative in
the past when it came to the gretl logo..., hehe.
cheers,
sven
8:24 a.m.
On Fri, 18 Sep 2015, Sven Schreiber wrote:
Yes that would probably be good, and I think somebody (Henrique?) at
some stage tried to do something about the icons, but maybe that was
just porting them to svg or something.
Also, Allin and Jack have pronounced themselves quite conservative in
the past when it came to the gretl logo..., hehe.
Don't you dare touch the little girl!!!
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
9:01 a.m.
Am 18.09.2015 um 10:24 schrieb Riccardo (Jack) Lucchetti:
On Fri, 18 Sep 2015, Sven Schreiber wrote:
> Yes that would probably be good, and I think somebody (Henrique?) at
> some stage tried to do something about the icons, but maybe that was
> just porting them to svg or something.
> Also, Allin and Jack have pronounced themselves quite conservative in
> the past when it came to the gretl logo..., hehe.
Don't you dare touch the little girl!!!
Even though little girls typically don't need a facelifting, the same
isn't necessarily true for logos. What I mean is that the technical
look&feel of the picture could use a modernization, which wouldn't imply
that a whole different picture or symbol is used.
But as Johannes also guessed, we are not graphical designers here. So
the question is who could do something like that with satisfactory results.
-sven
9:12 a.m.
El 18/09/15 a las 10:24, Riccardo (Jack) Lucchetti escribió:
On Fri, 18 Sep 2015, Sven Schreiber wrote:
> Yes that would probably be good, and I think somebody (Henrique?) at
> some stage tried to do something about the icons, but maybe that was
> just porting them to svg or something.
> Also, Allin and Jack have pronounced themselves quite conservative in
> the past when it came to the gretl logo..., hehe.
Don't you dare touch the little girl!!!
Without touching her, may be we can have at least a logo with a better
resolution.
I have this image below (probably with too much contrast), and Allin has
the book ;-))
http://www.ehu.eus/ignacio.diaz-emparanza/Hansel-and-Grethel.png
--
Ignacio Díaz-Emparanza
Departamento de Economía Aplicada III (Econometría y Estadística)
Universidad del País Vasco - Euskalherriko Unibertsitatea, UPV/EHU
Tfno: (+34) 94 601 3732
http://www.ehu.eus/ea3
1:43 p.m.
Em 18 de setembro de 2015 Ignacio Diaz-Emparanza escreveu:
El 18/09/15 a las 10:24, Riccardo (Jack) Lucchetti escribió:
> On Fri, 18 Sep 2015, Sven Schreiber wrote:
>
> Yes that would probably be good, and I think somebody (Henrique?) at
>> some stage tried to do something about the icons, but maybe that was
>> just porting them to svg or something.
>> Also, Allin and Jack have pronounced themselves quite conservative in
>> the past when it came to the gretl logo..., hehe.
>>
>
> Don't you dare touch the little girl!!!
>
Without touching her, may be we can have at least a logo with a better
resolution.
I have this image below (probably with too much contrast), and Allin has
the book ;-))
http://www.ehu.eus/ignacio.diaz-emparanza/Hansel-and-Grethel.png
Dear Sven,
I think it was our fellow Helio that made the porting ;-)
Gretl Team,
I'm thinking about a logo overhaul for a long time. But keeping our little
Gretel as beautiful as she already is :-) I think we could ask for a
designer's help.
Recently I've found a company called 99designs (
http://en.99designs.com.br/nonprofits/) that has a non-profit programme
that I believe we can ask for help.
If you guys think it's fine I can talk to them (they have offices in
Brazil, USA, Gemany and Australia).
Um abraço,
Henrique Andrade
2:08 p.m.
On Fri, 18 Sep 2015, Ignacio Diaz-Emparanza wrote:
El 18/09/15 a las 10:24, Riccardo (Jack) Lucchetti escribió:
> On Fri, 18 Sep 2015, Sven Schreiber wrote:
>
>> Yes that would probably be good, and I think somebody (Henrique?) at
>> some stage tried to do something about the icons, but maybe that was
>> just porting them to svg or something.
>> Also, Allin and Jack have pronounced themselves quite conservative in
>> the past when it came to the gretl logo..., hehe.
>
> Don't you dare touch the little girl!!!
Without touching her, may be we can have at least a logo with a better
resolution.
I have this image below (probably with too much contrast), and Allin has the
book ;-))
Yes, I do -- for which many thanks! It has long been on my agenda to
get some help from our digital art people to make a better version of
the gretl logo based on the image in the book. This discussion will
give me a kick in the pants to actually do it!
Allin
6:27 p.m.
Dear Allin,
I converted the image to icons. I hope it could help ;)
Best,
Henrique
2015-09-18 11:08 GMT-03:00 Allin Cottrell <cottrell(a)wfu.edu>:
On Fri, 18 Sep 2015, Ignacio Diaz-Emparanza wrote:
El 18/09/15 a las 10:24, Riccardo (Jack) Lucchetti escribió:
>
>> On Fri, 18 Sep 2015, Sven Schreiber wrote:
>>
>> Yes that would probably be good, and I think somebody (Henrique?) at
>>> some stage tried to do something about the icons, but maybe that was
>>> just porting them to svg or something.
>>> Also, Allin and Jack have pronounced themselves quite conservative in
>>> the past when it came to the gretl logo..., hehe.
>>>
>>
>> Don't you dare touch the little girl!!!
>>
>
> Without touching her, may be we can have at least a logo with a better
> resolution.
> I have this image below (probably with too much contrast), and Allin has
> the book ;-))
>
Yes, I do -- for which many thanks! It has long been on my agenda to get
some help from our digital art people to make a better version of the gretl
logo based on the image in the book. This discussion will give me a kick in
the pants to actually do it!
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
--
Henrique Andrade
3135
days inactive
3140
days old
14 comments
7 participants
participants (7)
-
Allin Cottrell -
Dirk Eddelbuettel -
Henrique Andrade -
Ignacio Diaz-Emparanza -
Johannes Lips -
Riccardo (Jack) Lucchetti -
Sven Schreiber