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: 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_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: 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 f

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