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

2013-02-21 Thread Stefano Lattarini
On 02/21/2013 03:32 PM, Stefano Lattarini wrote: >> Not yet; we first need a preparatory patch adjusting NEWS and HACKING (as >> well as few miscellaneous comments in tests and scripts). Then we can >> finally proceed with the re-shuffling of the Git repository -- which I >> guess will also have t

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

2013-02-21 Thread Stefano Lattarini
On 02/17/2013 03:57 PM, Stefano Lattarini wrote: > On 02/13/2013 07:39 PM, Stefano Lattarini wrote: >> >> Reference: >> >> >> OK, so far I've seen only positive feedback about this proposal. There >> are still some unresolved issues about how to

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

2013-02-17 Thread Stefano Lattarini
On 02/13/2013 07:39 PM, Stefano Lattarini wrote: > > Reference: > > > OK, so far I've seen only positive feedback about this proposal. There > are still some unresolved issues about how to handle beta releases; but > the related proposals can be

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

2013-02-13 Thread Stefano Lattarini
Reference: On 01/28/2013 08:48 PM, Stefano Lattarini wrote: > Severity: wishlist > > Recently, the need of a quick bug-fixing release 1.13.2 has shown some > issues with the current branching and versioning scheme of Automake. > > Let's first

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

2013-02-13 Thread Stefano Lattarini
Hi Diego. On 02/12/2013 06:50 PM, Diego Elio Pettenò wrote: > 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. >

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,

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 du

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,

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 o

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

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 th

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.

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, ... >

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 exactl

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.

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, ... >

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

2013-02-11 Thread Miles Bader
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, ... Or the widely used in FOSS 1.13.99... [sometimes they start at "

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

2013-02-11 Thread Diego Elio Pettenò
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", and 1.13.0 _and_ .1 were

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

2013-02-11 Thread Stefano Lattarini
Hi Diego, Jack, sorry for the late reply. On 02/01/2013 06:47 AM, Jack Kelly wrote: > Diego Elio Pettenò writes: >> On 31/01/2013 20:58, Jack Kelly wrote: >>> IMHO, that seems like a great way to cause trouble for unsuspecting >>> users. (Anyone remember KDE4.0?) Can you expand on why you think i

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

2013-01-31 Thread Jack Kelly
Diego Elio Pettenò writes: > On 31/01/2013 20:58, Jack Kelly wrote: >> IMHO, that seems like a great way to cause trouble for unsuspecting >> users. (Anyone remember KDE4.0?) Can you expand on why you think it's a >> good plan? > > Because unlike KDE, automake can put a big fat warning in the gene

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

2013-01-31 Thread Diego Elio Pettenò
On 31/01/2013 20:58, Jack Kelly wrote: > IMHO, that seems like a great way to cause trouble for unsuspecting > users. (Anyone remember KDE4.0?) Can you expand on why you think it's a > good plan? Because unlike KDE, automake can put a big fat warning in the generated configure that says "You're us

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

2013-01-31 Thread Jack Kelly
Diego Elio Pettenò writes: > Okay that sounds reasonable. I would be more toward 24 than 18 — maybe > going for 18 to the next "beta"-quality automake, 24 to the final > release. Speaking of which I would suggest that we call X.0 the betas, > and suggest general usage only when X.1 is out... IMHO

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

2013-01-31 Thread Diego Elio Pettenò
On 31/01/2013 13:47, Stefano Lattarini wrote: > But there is already such a discussion going on; see: > > > > Or did you mean something else? I would expect a more ... visible discussion. Honestly bugs are all nice and shiny but I don't expe

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

2013-01-31 Thread Stefano Lattarini
On 01/30/2013 04:30 AM, Daniel Herring wrote: > On Mon, 28 Jan 2013, Stefano Lattarini wrote: > >> Feedback, opinions, objections? > > There was a lot to read, and I confess to not giving it full justice. > > Others have already extolled the virtues of backwards compatibility. > > > Regarding

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

2013-01-31 Thread Diego Elio Pettenò
On 28/01/2013 20:48, Stefano Lattarini wrote: > Feedback, opinions, objections? First of all, I would like to hope that this is not going to be rushed through — it's an important and big change and I think having discussion about it with others might be a better idea. One thing that worries me at

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

2013-01-31 Thread Stefano Lattarini
Hi Diego. On 01/31/2013 12:46 PM, Diego Elio Pettenò wrote: > On 28/01/2013 20:48, Stefano Lattarini wrote: >> Feedback, opinions, objections? > > First of all, I would like to hope that this is not going to be rushed > through — it's an important and big change > Agreed. > and I think having di

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

2013-01-31 Thread Stefano Lattarini
On 01/30/2013 10:07 PM, Eric Dorland wrote: > > [SNIP PROPOSAL for new versioning scheme] > > I like it. > Glad to hear that :-) > I think it would mean that Debian could carry less > simultaneous automake packages at the same time, ie it would have a > separate package per major release and just

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

2013-01-30 Thread Eric Dorland
* Stefano Lattarini (stefano.lattar...@gmail.com) wrote: > Severity: wishlist > > Recently, the need of a quick bug-fixing release 1.13.2 has shown some > issues with the current branching and versioning scheme of Automake. > > Let's first see some background, to better understand the situation.

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

2013-01-29 Thread Daniel Herring
On Mon, 28 Jan 2013, Stefano Lattarini wrote: Feedback, opinions, objections? There was a lot to read, and I confess to not giving it full justice. Others have already extolled the virtues of backwards compatibility. Regarding some "why" questions, here's the manual entry on how versioning

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

2013-01-29 Thread Stefano Lattarini
On 01/29/2013 08:09 AM, Thien-Thi Nguyen wrote: > () Stefano Lattarini > () Mon, 28 Jan 2013 20:48:59 +0100 > >So I propose the following change in the Automake versioning scheme: >[...] > > Sounds good. Going further, you could maybe define notation (described > in HACKING) for categor

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

2013-01-29 Thread Stefano Lattarini
On 01/29/2013 01:18 PM, Peter Johansson wrote: > Hi Stefano, > Hi Peter and everybody, and thanks for the feedback. > [SNIP] > > Stefano Lattarini wrote: > >> So I propose the following change in the Automake versioning scheme: >> >>* Major releases should actually have the major version numbe

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

2013-01-29 Thread Dave Goodell
On Jan 29, 2013, at 6:18 AM CST, Peter Johansson wrote: > On 1/29/13 5:48 AM, Stefano Lattarini wrote: > >> Another plus of this new versioning scheme is that it will allow >> different minor releases, even with the same major version, to >> co-exist on the same system (that's because the $(APIVE

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

2013-01-29 Thread Peter Johansson
Hi Stefano, On 1/29/13 5:48 AM, Stefano Lattarini wrote: Severity: wishlist Recently, the need of a quick bug-fixing release 1.13.2 has shown some issues with the current branching and versioning scheme of Automake. Let's first see some background, to better understand the situation. Given t

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

2013-01-28 Thread Thien-Thi Nguyen
() Stefano Lattarini () Mon, 28 Jan 2013 20:48:59 +0100 So I propose the following change in the Automake versioning scheme: [...] Sounds good. Going further, you could maybe define notation (described in HACKING) for categories of changes (backward-{in}compatible, etc) and methodically u

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

2013-01-28 Thread Jack Kelly
Stefano Lattarini writes: > So I propose the following change in the Automake versioning scheme: > > * Major releases should actually have the major version number bumped. > That is, the next major Automake version will be 2.0, rather than > 1.14; and the major version after that will be

[IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository

2013-01-28 Thread Stefano Lattarini
Severity: wishlist Recently, the need of a quick bug-fixing release 1.13.2 has shown some issues with the current branching and versioning scheme of Automake. Let's first see some background, to better understand the situation. Given the typically long time between a major release 1.N and the ne