On 02/17/2013 03:57 PM, Stefano Lattarini wrote:
On 02/13/2013 07:39 PM, Stefano Lattarini wrote:
Reference:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13578
OK, so far I've seen only positive feedback about this proposal. There
are still some unresolved issues about how to handle beta
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 to be
On 02/13/2013 07:39 PM, Stefano Lattarini wrote:
Reference:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13578
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 seen as
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.
I
Hi Miles.
On 02/12/2013 12:50 AM, Miles Bader wrote:
Stefano Lattarini stefano.lattar...@gmail.com 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
2013/2/12 Stefano Lattarini stefano.lattar...@gmail.com:
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
Hi Miles.
On 02/12/2013 12:50 AM, Miles Bader wrote:
Stefano Lattarini stefano.lattar...@gmail.com 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
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
2013/2/12 Stefano Lattarini stefano.lattar...@gmail.com:
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
On 02/12/2013 09:25 AM, Miles Bader wrote:
2013/2/12 Stefano Lattarini stefano.lattar...@gmail.com:
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
2013/2/12 Stefano Lattarini stefano.lattar...@gmail.com:
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
On Tue, Feb 12, 2013 at 9:38 AM, Stefano Lattarini
stefano.lattar...@gmail.com wrote:
On 02/12/2013 09:25 AM, Miles Bader wrote:
2013/2/12 Stefano Lattarini stefano.lattar...@gmail.com:
But what if we want to have multiple betas for, say, Automake 1.14?
Today,
we can just have 1.13b, 1.13d,
* 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
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,
Nate Bargmann n...@n0nb.us 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
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
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
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
Hi Diego, Jack, sorry for the late reply.
On 02/01/2013 06:47 AM, Jack Kelly wrote:
Diego Elio Pettenò flamee...@flameeyes.eu 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
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 not
Stefano Lattarini stefano.lattar...@gmail.com 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...
On 31/01/2013 13:47, Stefano Lattarini wrote:
But there is already such a discussion going on; see:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13578
Or did you mean something else?
I would expect a more ... visible discussion. Honestly bugs are all nice
and shiny but I don't expect
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
Diego Elio Pettenò flamee...@flameeyes.eu 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
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 upgrade
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
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
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 some why
On 31/01/2013 13:47, Stefano Lattarini wrote:
But there is already such a discussion going on; see:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13578
Or did you mean something else?
I would expect a more ... visible discussion. Honestly bugs are all nice
and shiny but I don't expect
Diego Elio Pettenò flamee...@flameeyes.eu 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
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 using
Diego Elio Pettenò flamee...@flameeyes.eu 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
* 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.
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
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 $(APIVERSION)
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 number bumped.
On 01/29/2013 08:09 AM, Thien-Thi Nguyen wrote:
() Stefano Lattarini stefano.lattar...@gmail.com
() 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
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
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
Stefano Lattarini stefano.lattar...@gmail.com 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
40 matches
Mail list logo
