Bruno Haible br...@clisp.org ha escrit:
gnulib-1836.86a37.1.1
If you do this, you can never again switch to a different versioning
scheme.
Not quite so. What I meant is that the part between `-' and `1.1' is
to be ignored (it cannot be used for ordering anyway). In this case
I see no
Sergey Poznyakoff wrote:
gnulib-1836.86a37.1.1
If you do this, you can never again switch to a different versioning
scheme.
Not quite so. What I meant is that the part between `-' and `1.1' is
to be ignored (it cannot be used for ordering anyway).
Does this match what the TP
Sergey Poznyakoff wrote:
I am going to submit the updated gnulib.pot to TP. Before this,
I'd like to change its versioning scheme so that it coincides with the
version reported by `gnilib-tool --version'. E.g. this potfile will be
named gnulib-0.0.1991-dbebf.pot.
After discussing this with
Sergey Poznyakoff wrote:
the TP robot assumes that version numbers are growing
from version to version and relies on this for sorting. Given
this, I'll continue using the old numbering scheme for potfiles
(gnulib-major.minor.pot), but before submitting the potfile, I'll create
a tag
Bruno Haible br...@clisp.org ha escrit:
How about changing the versioning scheme to
gnulib-1.1.2009.03.26
or
gnulib-1.1.1836.86a37
It would be better to place TP version at the end, as in:
gnulib-1836.86a37.1.1
This should work with the TP software.
Could you also generate and
Sergey Poznyakoff wrote:
It would be better to place TP version at the end, as in:
gnulib-1836.86a37.1.1
If you do this, you can never again switch to a different versioning scheme.
What if we abandon 'git' for something better in 5 years? Then all major
versions will have to be 5000.
Hello,
I am going to submit the updated gnulib.pot to TP. Before this,
I'd like to change its versioning scheme so that it coincides with the
version reported by `gnilib-tool --version'. E.g. this potfile will be
named gnulib-0.0.1991-dbebf.pot. Does it seem a good idea?
Regards,
Sergey
