Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository

2013-02-12 Thread Diego Elio Pettenò 
On 12/02/2013 17:44, Stefano Lattarini wrote:
> Ah, ok, so in the end you already agree that this is a "documentation"
> issue rather than a versioning one.  Please correct me if I'm wrong!

I guess it's a matter of perception.

I honestly don't see the point of beta software if nobody's using it, as
it would just actually be an alpha for the beta (.0/.1 releases) which
then becomes stable (.2+ — sometimes).

If we go with a new major version we could have:

2.0.x -> new major, testing branch (let's not call it beta!), all fine
but it throws a huge warning at runtime that the branch is not finalized
yet and thus that it should not be used for distributed software

2.1.x -> new major, stable branch, micro versions for bugfix only

2.2.x -> new major, new features branch, introduces deprecation warnings
for features leaving in 3.0, possibly some opt-in versions of features
becoming standard in 3.0.

_If needed_ only:

2.90.x -> experimental branch for the upcoming 3.0 testing branch

-- 
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/

Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository

2013-02-12 Thread Stefano Lattarini 
On 02/12/2013 04:15 PM, Diego Elio Pettenò wrote:
> On 12/02/2013 09:26, Stefano Lattarini wrote:
>>> Given that 1.12.0 was "not really final release",
>>>
>> Why not?
> 
> AM_PROG_MKDIR_P.
>
Ah, right.  I had forgot about that (selective memory? A dangerous
thing).

>> This is true, but is only due to the fact that I released them with
>> too much haste, without giving time for proper testing.  IOW, this
>> debacle has been a fault of mine, not of the naming scheme.
> 
> True, but it shows a pattern: most people (even developers who get
> involved in the process, such as Paolo) do not even look at the beta
> versions..
>
That is not something automake can do anything about.  Releasing
beta versions whose version numbers suggests they are actually
stable versions is a solution worse than the problem.  But you might
correctly point out that, due to lack of proper testing, this is
already what we are doing right now (albeit not by choice); so the
issue becomes at this point a documentation issue (that is, we should
find a way to inform the users that early stable versions of new major
releases might turn out to be lamentably unstable in practice, if
nobody has given the betas proper testing).  See again below.

>> I don't see any need for this; everyone knows that a new major release
>> is more likely to contain bugs and rough edges.  (OTOH, this is not
>> excuse to be sloppy and hastily in the release process as I've been
>> for 1.13; but avoiding repeating the mistake in the future will only
>> require more care and attention from the maintainer, and not a change
>> of policy).
> 
> True, but a new beta also is also more likely to contain bugs and rough
> edges... so it's basically the same thing, thus why I'm saying that it
> should just be the same. Put out the new major at "not stable yet", try
> it out all around, then make a release to call it stable.
>
This sounds sensible, but I think it should be done in addition to the
usual release of "classic" beta versions (with the hope that someone
will get to testing them eventually).  And if we agree on this approach,
the only required change would be a new section about this versioning
and stability issues in the Automake manual (and/or in the Autotools
Mythbuster guide).  As usual, patches are welcome (this is not really
my itch).

>> Any link about this?  The info I found on Google doesn't seem very
>> helpful nor relevant.
> 
> I'm afraid I don't have anything that Google wouldn't have. But at least
> for 2.2, it was declared stable much later than ".0" if I'm not
> mistaken.
>
That happened with Python as well, and I guess with many other softwares
who did a major version bump with non-trivial backward incompatibilities.

> Basically, it would be like making policy that the new major
> branch is not stable until we say it is.. which is really what we need.
> 
Ah, ok, so in the end you already agree that this is a "documentation"
issue rather than a versioning one.  Please correct me if I'm wrong!

Thanks,
  Stefano

Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository

2013-02-12 Thread Daniel Herring 
I like the -alpha/-beta/-rcN markings.  As someone who often tracks 
cutting-edge stuff, it is nice to have a clear indicator of how stable the 
author things something is.  This info helps the user do a quick 
cost/benefit estimate when deciding what version to use today.


- Daniel

Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository

2013-02-12 Thread Miles Bader 
Nate Bargmann  writes:
> I was advised by a Debian maintainer to use tilde '~' as the
> separator as any text following it will be considered "older".  For
> example, in our project 'Hamlib-3.0~git' is "older" than
> 'Hamlib-3.0' will be once released.  A hyphen or underscore trips
> this logic up, as I understand it, for both .deb and .rpm formats.

This is a Debian-specific syntax, for use in Debian package version
numbers.  It's a handy way for the Debian maintainer to directly
represent various existing package version naming schemes with only
mechanical changes (typical, replacing a "_" or "-" with "~"), but I
don't think there's any intent that upstreams should adopt this syntax
directly (though I suppose it doesn't particularly hurt if they
do...).

-miles

-- 
Abstainer, n. A weak person who yields to the temptation of denying himself a
pleasure. A total abstainer is one who abstains from everything but
abstention, and especially from inactivity in the affairs of others.

Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository

2013-02-12 Thread Diego Elio Pettenò 
On 12/02/2013 09:26, Stefano Lattarini wrote:
>> Given that 1.12.0 was "not really final release",
>>
> Why not?

AM_PROG_MKDIR_P.

> This is true, but is only due to the fact that I released them with
> too much haste, without giving time for proper testing.  IOW, this
> debacle has been a fault of mine, not of the naming scheme.

True, but it shows a pattern: most people (even developers who get
involved in the process, such as Paolo) do not even look at the beta
versions..

> I don't see any need for this; everyone knows that a new major release
> is more likely to contain bugs and rough edges.  (OTOH, this is not
> excuse to be sloppy and hastily in the release process as I've been
> for 1.13; but avoiding repeating the mistake in the future will only
> require more care and attention from the maintainer, and not a change
> of policy).

True, but a new beta also is also more likely to contain bugs and rough
edges... so it's basically the same thing, thus why I'm saying that it
should just be the same. Put out the new major at "not stable yet", try
it out all around, then make a release to call it stable.

> Any link about this?  The info I found on Google doesn't seem very
> helpful nor relevant.

I'm afraid I don't have anything that Google wouldn't have. But at least
for 2.2, it was declared stable much later than ".0" if I'm not
mistaken. Basically, it would be like making policy that the new major
branch is not stable until we say it is.. which is really what we need.

-- 
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/

Re: subdir-objects and generated file names

2013-02-12 Thread Stefano Lattarini 
On 02/12/2013 03:27 PM, Vincent Torri wrote:
> On Tue, Feb 12, 2013 at 9:24 AM, Stefano Lattarini
>  wrote:
>> On 02/12/2013 07:28 AM, Vincent Torri wrote:
>>> Hey
>>>
>>> I'm porting a lib to a non recursive make build system. I have a
>>> single top level Makefile.am which has:
>>>
>>> AUTOMAKE_OPTIONS = subdir-objects
>>>
>>> include src/lib/css/Makefile.mk
>>>
>>> In that Makefile.mk, yacc is called and generates the file
>>> src_lib_css_libecss_la-ecss_grammar.h from ecss_grammar.y (both of
>>> them are in src/lib/css)
>>>
>>> is it possible to keep the name grammar.h
>>>
>> You means 'ecss_grammar.y', right?
> 
> no, ecss_grammar.h.
> 
Yes, that what I meant.  Sorry for the typo and the confusion.

Regards,
  Stefano

Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository

2013-02-12 Thread Nate Bargmann 
* On 2013 12 Feb 03:08 -0600, Vincent Torri wrote:
> in our project, we append _beta and _rc (or _rc1, _rc2 etc...) for
> beta and release candidate. It's sufficiently explicit. For example,
> 1.14.0_beta

I was advised by a Debian maintainer to use tilde '~' as the separator
as any text following it will be considered "older".  For example, in
our project 'Hamlib-3.0~git' is "older" than 'Hamlib-3.0' will be once
released.  A hyphen or underscore trips this logic up, as I understand
it, for both .deb and .rpm formats.  While this is good practice from a
package mainter's POV, it has not been a problem as we ask that such
code not be packaged by distributions.  The extra text is a human
convenience add-on.

Also, the practice of using the "prior" released version number as the
base for the next version's beta is a bit confusing to me.  The Linux
kernel model of the *next* planned release tagged with an additional
"rc1", "beta", "git", what-have-you always seemed more logical to me, at
least.  Our project adopted this approach of versioning of base +1
(always arbitrary) for the next planned released so that beta testers
and developers are well aware of the next planned version and that
additional characters following a '~' means a yet to be released version.

In other words, 1.14~git, 1.14~beta, 1.14~rc1, make more sense to me for
the forthcoming 1.14 release than using 1.13+whatever which magically
is promoted to 1.14 upon release.  JMHO.

- Nate

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us

Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository

2013-02-12 Thread Vincent Torri 
On Tue, Feb 12, 2013 at 9:38 AM, Stefano Lattarini
 wrote:
> On 02/12/2013 09:25 AM, Miles Bader wrote:
>> 2013/2/12 Stefano Lattarini :
> But what if we want to have multiple betas for, say, Automake 1.14?  
> Today,
> we can just have 1.13b, 1.13d, 1.13f, ...; how can we do so with the 
> scheme
> you are proposing?

 There's always 1.14.0.1, ...

>>> Yuck; the new versioning scheme is done exactly to avoid that kind
>>> of overly long version numbers
>>
>> Well, I agree in general that too many components is yucky, but keep
>> in mind that these _aren't releases_, so assigning them "awkward"
>> version numbers doesn't really seem all that annoying.  These really
>> aren't part of the historical record.  The existing naming scheme for
>> betas does the same thing (uses "weird" version numbers), but is
>> problematic because it's not mechanically consistent with "ordinary"
>> version numbers (and so screws up cases such as packaging software).
>>
> Mostly fair points; but the biggest issue with this proposal (not
> sure why I didn't think of it before, sorry) is that it is not at
> all clear that a version like "1.13.0.1" is supposed to be a beta
> release.  People will easily mistake it for a stable release.  OK,
> we can add warnings and info and whatnot in the manual and homepage
> of automake about our unusual versioning scheme, but how many people
> will read them?  And in the end, even those who do will likely be
> just annoyed by the fact that we are trying to be clever and invent
> a new versioining scheme incompatible with every other existing one.
>
> No, if we want to change the versioning scheme for beta and rc
> versions, we want the new scheme to be already used and well known.

in our project, we append _beta and _rc (or _rc1, _rc2 etc...) for
beta and release candidate. It's sufficiently explicit. For example,
1.14.0_beta

Vincent Torri

Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository

2013-02-12 Thread Miles Bader 
2013/2/12 Stefano Lattarini :
> Mostly fair points; but the biggest issue with this proposal (not
> sure why I didn't think of it before, sorry) is that it is not at
> all clear that a version like "1.13.0.1" is supposed to be a beta
> release.  People will easily mistake it for a stable release.

How about this:  pick whatever scheme you like for other reasons, and
then add "-beta" to those version numbers.  In other words, a purely
informational suffix, which is not actually necessary for version
sorting...

(note that the "a", "b", etc, suffixes have the same issue)

-miles

-- 
Cat is power.  Cat is peace.

Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository

2013-02-12 Thread Stefano Lattarini 
On 02/12/2013 09:25 AM, Miles Bader wrote:
> 2013/2/12 Stefano Lattarini :
 But what if we want to have multiple betas for, say, Automake 1.14?  Today,
 we can just have 1.13b, 1.13d, 1.13f, ...; how can we do so with the scheme
 you are proposing?
>>>
>>> There's always 1.14.0.1, ...
>>>
>> Yuck; the new versioning scheme is done exactly to avoid that kind
>> of overly long version numbers
> 
> Well, I agree in general that too many components is yucky, but keep
> in mind that these _aren't releases_, so assigning them "awkward"
> version numbers doesn't really seem all that annoying.  These really
> aren't part of the historical record.  The existing naming scheme for
> betas does the same thing (uses "weird" version numbers), but is
> problematic because it's not mechanically consistent with "ordinary"
> version numbers (and so screws up cases such as packaging software).
>
Mostly fair points; but the biggest issue with this proposal (not
sure why I didn't think of it before, sorry) is that it is not at
all clear that a version like "1.13.0.1" is supposed to be a beta
release.  People will easily mistake it for a stable release.  OK,
we can add warnings and info and whatnot in the manual and homepage
of automake about our unusual versioning scheme, but how many people
will read them?  And in the end, even those who do will likely be
just annoyed by the fact that we are trying to be clever and invent
a new versioining scheme incompatible with every other existing one.

No, if we want to change the versioning scheme for beta and rc
versions, we want the new scheme to be already used and well known.

> I do agree that removing the leading "1." might be a good idea if it's
> meaningless in practice.  Linux's similar action was good.
> 
> -miles
> 
> --
> Cat is power.  Cat is peace.

Thanks,
  Stefano

Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository

2013-02-12 Thread Miles Bader 
2013/2/12 Stefano Lattarini :
>>> But what if we want to have multiple betas for, say, Automake 1.14?  Today,
>>> we can just have 1.13b, 1.13d, 1.13f, ...; how can we do so with the scheme
>>> you are proposing?
>>
>> There's always 1.14.0.1, ...
>>
> Yuck; the new versioning scheme is done exactly to avoid that kind
> of overly long version numbers

Well, I agree in general that too many components is yucky, but keep
in mind that these _aren't releases_, so assigning them "awkward"
version numbers doesn't really seem all that annoying.  These really
aren't part of the historical record.  The existing naming scheme for
betas does the same thing (uses "weird" version numbers), but is
problematic because it's not mechanically consistent with "ordinary"
version numbers (and so screws up cases such as packaging software).

I do agree that removing the leading "1." might be a good idea if it's
meaningless in practice.  Linux's similar action was good.

-miles

--
Cat is power.  Cat is peace.

Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository

2013-02-12 Thread Stefano Lattarini 
On 02/11/2013 04:00 PM, Diego Elio Pettenò wrote:
> On 11/02/2013 15:54, Stefano Lattarini wrote:
>> But what if we want to have multiple betas for, say, Automake 1.14?  Today,
>> we can just have 1.13b, 1.13d, 1.13f, ...; how can we do so with the scheme
>> you are proposing?
> 
> Given that 1.12.0 was "not really final release",
>
Why not?

> and 1.13.0 _and_ .1 were "not really final releases",
>
This is true, but is only due to the fact that I released them with
too much haste, without giving time for proper testing.  IOW, this
debacle has been a fault of mine, not of the naming scheme.

> I would suggest calling the first beta as 1.14.0 with the big fat
> warning,
>
I don't see any need for this; everyone knows that a new major release
is more likely to contain bugs and rough edges.  (OTOH, this is not
excuse to be sloppy and hastily in the release process as I've been
for 1.13; but avoiding repeating the mistake in the future will only
require more care and attention from the maintainer, and not a change
of policy).

> then everybody's satisfied (no missing features, for instance),
> it rolls as 1.14.4 (say) "really final release".
>
> This should be more or less equivalent to Apache's versioning,
>
Any link about this?  The info I found on Google doesn't seem very
helpful nor relevant.

> and leads to decency, I'd say.
> 

Thanks,
  Stefano

Re: subdir-objects and generated file names

2013-02-12 Thread Stefano Lattarini 
On 02/12/2013 07:28 AM, Vincent Torri wrote:
> Hey
> 
> I'm porting a lib to a non recursive make build system. I have a
> single top level Makefile.am which has:
> 
> AUTOMAKE_OPTIONS = subdir-objects
> 
> include src/lib/css/Makefile.mk
> 
> In that Makefile.mk, yacc is called and generates the file
> src_lib_css_libecss_la-ecss_grammar.h from ecss_grammar.y (both of
> them are in src/lib/css)
> 
> is it possible to keep the name grammar.h 
>
You means 'ecss_grammar.y', right?

> and not src_lib_css_libecss_la-ecss_grammar.h while using the
> subdir-objects option ?
>
Not really; but you can at least shorten the name considerably
using the "_SHORTNAME" trick:



HTH,
  Stefano

Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository

2013-02-12 Thread Stefano Lattarini 
Hi Miles.

On 02/12/2013 12:50 AM, Miles Bader wrote:
> Stefano Lattarini  writes:
>> But what if we want to have multiple betas for, say, Automake 1.14?  Today,
>> we can just have 1.13b, 1.13d, 1.13f, ...; how can we do so with the scheme
>> you are proposing?
> 
> There's always 1.14.0.1, ...
>
Yuck; the new versioning scheme is done exactly to avoid that kind
of overly long version numbers -- otherwise, we could just have
1.13.1.1 as bug-fixing release, 1.13.2 as new minor release, and
1.14 as new major release.  But if that leading "1" is going to
remain unchanged anyway, what is the point of keeping it?  It's
just "visual noise" IMO.

(In addition, the current version-checking code in Automake only
grasps version numbers with at most three numbers).

> Or the widely used in FOSS 1.13.99...
> [sometimes they start at "90", to leave room for updates,
>
This might work.  But see below.

> but I suppose you could always just use .99.1, .99.2, ...]
>
(No, because, as said above, I don't want to have version numbers
with four or more components)

Anyway, before changing the current naming scheme for beta versions,
we'd need some numbers about which the most widespread naming
schemes are, and weight their advantages and disadvantages w.r.t.
our "workflow"; we don't want to trade the current naming scheme
for another that is only marginally more popular, or for a one that
will give use a new and bigger set of problems down the road.

Thanks,
  Stefano