M4 versioning and release management

[Aidan Skinner <ai...@apache.org>]

Two things about our next release. Firstly, who is going to release manage
it? I am going to be away for chunks of critical time so won't be able to do
it this time round.

Secondly, and possibly more contraversially, what shall we do about version
numbers? Having everything using the same version would be quite good.

The C++ requirements seem to be quite restrictive. Linux Kernel/APR style
would be my preference, kicking us to 0.4.0 for everything from 0.3 / M3.

- Aidan
-- 
Apache Qpid - World Domination through Advanced Message Queueing
http://cwiki.apache.org/qpid
"Nine-tenths of wisdom consists in being wise in time." - Theodore Roosevelt

Re: M4 versioning and release management

[Rafael Schloming <ra...@redhat.com>]

Robert Greig wrote:
> 2008/10/10 Carl Trieloff <cc...@redhat.com>:
> 
>> Note sure everything changes between version is correct, more like changed a
>> lot from first cut of
>> something until it has been around a while. The API between M3 and M4 C++
>> are the same, same
>> goes for Python, JMS is JMS.
> 
> I thought the Python API was generated from the protocol xml?

It is. There are no protocol changes between M3 and M4.

--Rafael

Re: M4 versioning and release management

[Carl Trieloff <cc...@redhat.com>]

Robert Greig wrote:
> 2008/10/10 Carl Trieloff <cc...@redhat.com>:
>
>   
>> Note sure everything changes between version is correct, more like changed a
>> lot from first cut of
>> something until it has been around a while. The API between M3 and M4 C++
>> are the same, same
>> goes for Python, JMS is JMS.
>>     
>
> I thought the Python API was generated from the protocol xml?
>   

Rafi is the one to comment, but things like QMF and QMFC will be 
un-affected by protocol updates, as they
are not protocol APIs.

>   
>> I expect that we would NOT be altering the API much between releases, and
>> when we do we provide
>> compatibility. I know we where not in this mode in M1 timeframe but my view
>> is that we need to be now.
>>     
>
> Yes I think that will be essential.
>
> RG
>   

Re: M4 versioning and release management

[Robert Greig <ro...@gmail.com>]

2008/10/10 Carl Trieloff <cc...@redhat.com>:

> Note sure everything changes between version is correct, more like changed a
> lot from first cut of
> something until it has been around a while. The API between M3 and M4 C++
> are the same, same
> goes for Python, JMS is JMS.

I thought the Python API was generated from the protocol xml?

> I expect that we would NOT be altering the API much between releases, and
> when we do we provide
> compatibility. I know we where not in this mode in M1 timeframe but my view
> is that we need to be now.

Yes I think that will be essential.

RG

Re: M4 versioning and release management

[Carl Trieloff <cc...@redhat.com>]

Robert Greig wrote:
> 2008/10/8 Aidan Skinner <ai...@apache.org>:
>
>   
>> It implies that the API is immature, which it is. The only stable API that
>> I'm aware of Qpid having is the JMS one. Everything else has a tendancy to
>> change / be completely rewritten between versions.
>>     
>
> This highlights the insanity (in my view) of basing an API on the
> protocol. I have already made my position on this clear in the past so
> I won't labour the point!
>
> In general, I think people expect API compatibility within major
> versions. We would need an API migration plan for non-major releases
> too - perhaps some backwards compatibility but with deprecation.
>
> I think that many people view the version number as an indication of
> maturity. API compatibility is just *expected* from any professional
> organisation that has any understanding of enterprise requirements.
>
> RG
>   

Note sure everything changes between version is correct, more like 
changed a lot from first cut of
something until it has been around a while. The API between M3 and M4 
C++ are the same, same
goes for Python, JMS is JMS. The new classes that where just added for 
HA don't break any of the
existing classes and  there is a thin layer in the client to protect 
against API thrashing. I think the
exception is WCF added for M4. Yes I know we can do more on the APIs & 
as developers we always
want to keep things open to change but...

I expect that we would NOT be altering the API much between releases, 
and when we do we provide
compatibility. I know we where not in this mode in M1 timeframe but my 
view is that we need to be now.

Or put another way, if someone created a new client for perl, I would 
expect the API to change for a
while, but then stabilize. There will always be something in Qpid that 
is new. It would be better to
create a table and show users which APIs are considered stable, and not 
tar the everything with the
maturity level of new API's which are in minority in the project.

Carl.

Re: M4 versioning and release management

[Carl Trieloff <cc...@redhat.com>]

> Exactly. Is there any plan or energy pent up for working on the API?
> I'm just getting going here, I know, but the C++ API seems overly
> complicated for its purposes. I'd be willing to expend a little energy
> on this area if there's support.
>
>   
yes, it has come up a few times. would be great to do for M5. Alan has 
ranted the most
about it so I would ping him when we get into M5.

Carl.

RE: M4 versioning and release management

[Steve Huston <sh...@riverace.com>]

> -----Original Message-----
> From: Robert Greig [mailto:robert.j.greig@gmail.com] 
> ...
> 2008/10/8 Aidan Skinner <ai...@apache.org>:
> 
> > It implies that the API is immature, which it is. The only 
> stable API that
> > I'm aware of Qpid having is the JMS one. Everything else 
> has a tendancy to
> > change / be completely rewritten between versions.
> 
> This highlights the insanity (in my view) of basing an API on the
> protocol. I have already made my position on this clear in the past
so
> I won't labour the point!

I'm glad to hear this from someone who's been around this project for
a while.

> In general, I think people expect API compatibility within major
> versions. We would need an API migration plan for non-major releases
> too - perhaps some backwards compatibility but with deprecation.
> 
> I think that many people view the version number as an indication of
> maturity. API compatibility is just *expected* from any professional
> organisation that has any understanding of enterprise requirements.

Exactly. Is there any plan or energy pent up for working on the API?
I'm just getting going here, I know, but the C++ API seems overly
complicated for its purposes. I'd be willing to expend a little energy
on this area if there's support.

-Steve

Re: M4 versioning and release management

[Robert Greig <ro...@gmail.com>]

2008/10/8 Aidan Skinner <ai...@apache.org>:

> It implies that the API is immature, which it is. The only stable API that
> I'm aware of Qpid having is the JMS one. Everything else has a tendancy to
> change / be completely rewritten between versions.

This highlights the insanity (in my view) of basing an API on the
protocol. I have already made my position on this clear in the past so
I won't labour the point!

In general, I think people expect API compatibility within major
versions. We would need an API migration plan for non-major releases
too - perhaps some backwards compatibility but with deprecation.

I think that many people view the version number as an indication of
maturity. API compatibility is just *expected* from any professional
organisation that has any understanding of enterprise requirements.

RG

Re: M4 versioning and release management

[Aidan Skinner <ai...@apache.org>]

On Wed, Oct 8, 2008 at 11:04 AM, Robert Godfrey <ro...@gmail.com> wrote:

> 2008/10/8 Aidan Skinner <ai...@apache.org>:

> new version of the protocol.  Further I think that we should as a
> project strive to make sure that all clients/brokers move to a new
> version of the protocol *at the same time*.  I think the situation we
> have currently is very poor.

+1

> My view is that the first step to getting to any non-zero major number
> *has* to be getting all the components to have some common version of
> AMQP which they all speak.

+1

>> If we go to 1.x, the next release will almost certainly have to be 2.x and
>> then 3.x and 4.x etc. until we stabilise the APIs. We'd end up shipping Qpid
>> 10.something before it settled down.
>
> As above the APIs are driven off the protocol API.  This, I think, is
> a very proper point to have a major version increase.  I doubt that
> there'll be more than 1 or two more major protocol releases this
> decade.

They're not solely dependent on the protocol though. Major protocol
release will necessitate API changes, particularly for the rawer
clients. But there may be other changes to APIs that are required
independent of that.

I think we should move to a non-zero major number when all the
supported clients speak 0-10 and we've agreed that they are API
stable. I don't think we're there yet for M3+1.

- Aidan
-- 
Apache Qpid - World Domination through Advanced Message Queueing
http://cwiki.apache.org/qpid
"Nine-tenths of wisdom consists in being wise in time." - Theodore Roosevelt

Re: M4 versioning and release management

[Robert Godfrey <ro...@gmail.com>]

2008/10/8 Aidan Skinner <ai...@apache.org>:
> On Wed, Oct 8, 2008 at 10:33 AM, Robert Godfrey <ro...@gmail.com>wrote:
>
>
>> I think the real issue for me is that not all clients/brokers are
>> currently speaking the same version of AMQP; so we have API
>> inconsistency within the project.  If everything were speaking
>> AMQP0-10 then I would be fine in moving to a 1.x.  If the version of
>> AMQP then moves forward, and the derived APIs change then, as per the
>> Apache guidelines linked to by Aidan, we can change the major version
>> number.
>
>
> Having everything speak 0-10 would be good, but is unrelated to having a
> stable API.
>
> The protocol version may drive some changes, but there's a lot of churn in
> the C++ API between M1, M2 and M3,

Yes - because the C++ API follows the AMQP API, as it did between M1
(0-8), M2 (0-9 and 0-9WIP) and M3(0-10 for C++)

>  the Python and Ruby clients are quite
> fast changing,

Since they are generated from the AMQP spec.

>The .Net client has been totally rewritten for 0-10. There is
> no supported lower level API for the Java client at all.

Again driven by the AMQP protocol version.


What I am saying is that since (other than JMS) we have no protocol
independent APIs, the logical point at which the major version number
changes should be the point at which Qpid *as a whole* has moved to a
new version of the protocol.  Further I think that we should as a
project strive to make sure that all clients/brokers move to a new
version of the protocol *at the same time*.  I think the situation we
have currently is very poor.

If we declare a major version now, then when we move the Java broker
to 0-10 the APIs need to work with it necessarily change and we should
change the major version number.

Until we have consistency on the (protocol) APIs supported by the
brokers, we will not have stability in the programming APIs offered by
the clients.

My view is that the first step to getting to any non-zero major number
*has* to be getting all the components to have some common version of
AMQP which they all speak.

> I do agree with Robert that we have enough maturity and existing users
>> to justify a non 0.x version numbering.  Skipping from 0.3 to 1.4
>> without ever having a 1.0 would seem somewhat odd to me though :-)
>>
>
> A non 0.x version number isn't about being production ready, and it
> certainly isn't about existing users. It's about making a statement about
> the stability of the APIs that we're shipping and an implicit promise that
> it won't churn that often.
>
> If we go to 1.x, the next release will almost certainly have to be 2.x and
> then 3.x and 4.x etc. until we stabilise the APIs. We'd end up shipping Qpid
> 10.something before it settled down.

As above the APIs are driven off the protocol API.  This, I think, is
a very proper point to have a major version increase.  I doubt that
there'll be more than 1 or two more major protocol releases this
decade.

-- Rob

Re: M4 versioning and release management

[Aidan Skinner <ai...@apache.org>]

On Wed, Oct 8, 2008 at 10:33 AM, Robert Godfrey <ro...@gmail.com>wrote:


> I think the real issue for me is that not all clients/brokers are
> currently speaking the same version of AMQP; so we have API
> inconsistency within the project.  If everything were speaking
> AMQP0-10 then I would be fine in moving to a 1.x.  If the version of
> AMQP then moves forward, and the derived APIs change then, as per the
> Apache guidelines linked to by Aidan, we can change the major version
> number.


Having everything speak 0-10 would be good, but is unrelated to having a
stable API.

The protocol version may drive some changes, but there's a lot of churn in
the C++ API between M1, M2 and M3, the Python and Ruby clients are quite
fast changing, The .Net client has been totally rewritten for 0-10. There is
no supported lower level API for the Java client at all.

I do agree with Robert that we have enough maturity and existing users
> to justify a non 0.x version numbering.  Skipping from 0.3 to 1.4
> without ever having a 1.0 would seem somewhat odd to me though :-)
>

A non 0.x version number isn't about being production ready, and it
certainly isn't about existing users. It's about making a statement about
the stability of the APIs that we're shipping and an implicit promise that
it won't churn that often.

If we go to 1.x, the next release will almost certainly have to be 2.x and
then 3.x and 4.x etc. until we stabilise the APIs. We'd end up shipping Qpid
10.something before it settled down.

- Aidan

-- 
Apache Qpid - World Domination through Advanced Message Queueing
http://cwiki.apache.org/qpid
"Nine-tenths of wisdom consists in being wise in time." - Theodore Roosevelt

Re: M4 versioning and release management

[Robert Greig <ro...@gmail.com>]

2008/10/8 Robert Godfrey <ro...@gmail.com>:

> I think the real issue for me is that not all clients/brokers are
> currently speaking the same version of AMQP; so we have API
> inconsistency within the project.

Yes I agree that this is a major issue for the project - whether we
call the next release M4, 0.34 or Fred.

RG

Re: M4 versioning and release management

[Robert Godfrey <ro...@gmail.com>]

2008/10/8 Aidan Skinner <ai...@apache.org>:
> On Tue, Oct 7, 2008 at 8:39 PM, Robert Greig <ro...@gmail.com>wrote:
>
>
>> Do we want to have the major version as zero? That implies to me that
>> qpid is immature, which I would argue is not the case. The codebase
>
>
> It implies that the API is immature, which it is. The only stable API that
> I'm aware of Qpid having is the JMS one. Everything else has a tendancy to
> change / be completely rewritten between versions.
>
> I don't think that we're in a position to be offering source compatible APIs
> at this point or in the immediate future either. AMQP 1.0 is likely to cause
> some churn, particularly with the lower level clients like Ruby.
>
>
>> has been evolving over the space of several years now and there are
>> many production deployments of several components (e.g. I personally
>> know about significant usage of the java broker and client).
>>
>
> Being production ready is different from being API-stable and maintaining
> source compatibility between releases. The API compatibility is the
> objective information encoded in APR-style [1] version numbers.
>
> I know in some worlds having a large version number is taken to imply a
> certain level of maturity. That view is as often as not innaccurate. It is
> always highly subjective.
>
> - Aidan
>
> [1] http://apr.apache.org/versioning.html


The Apache guidelines you linked to make a clear case for major
version numbers being tied to API compatibility.

I think the real issue for me is that not all clients/brokers are
currently speaking the same version of AMQP; so we have API
inconsistency within the project.  If everything were speaking
AMQP0-10 then I would be fine in moving to a 1.x.  If the version of
AMQP then moves forward, and the derived APIs change then, as per the
Apache guidelines linked to by Aidan, we can change the major version
number.

I do agree with Robert that we have enough maturity and existing users
to justify a non 0.x version numbering.  Skipping from 0.3 to 1.4
without ever having a 1.0 would seem somewhat odd to me though :-)

-- Rob

Re: M4 versioning and release management

[Aidan Skinner <ai...@apache.org>]

On Tue, Oct 7, 2008 at 8:39 PM, Robert Greig <ro...@gmail.com>wrote:


> Do we want to have the major version as zero? That implies to me that
> qpid is immature, which I would argue is not the case. The codebase


It implies that the API is immature, which it is. The only stable API that
I'm aware of Qpid having is the JMS one. Everything else has a tendancy to
change / be completely rewritten between versions.

I don't think that we're in a position to be offering source compatible APIs
at this point or in the immediate future either. AMQP 1.0 is likely to cause
some churn, particularly with the lower level clients like Ruby.


> has been evolving over the space of several years now and there are
> many production deployments of several components (e.g. I personally
> know about significant usage of the java broker and client).
>

Being production ready is different from being API-stable and maintaining
source compatibility between releases. The API compatibility is the
objective information encoded in APR-style [1] version numbers.

I know in some worlds having a large version number is taken to imply a
certain level of maturity. That view is as often as not innaccurate. It is
always highly subjective.

- Aidan

[1] http://apr.apache.org/versioning.html
-- 
Apache Qpid - World Domination through Advanced Message Queueing
http://cwiki.apache.org/qpid
"Nine-tenths of wisdom consists in being wise in time." - Theodore Roosevelt

Re: M4 versioning and release management

[Marnie McCormack <ma...@googlemail.com>]

I like Robert's suggestion, and I'm in favour of moving to a 1.x release.

I also like Rafi's volunteering, way to go !

Marnie

On Tue, Oct 7, 2008 at 8:39 PM, Robert Greig <ro...@gmail.com>wrote:

> 2008/10/7 Aidan Skinner <ai...@apache.org>:
>
> > The C++ requirements seem to be quite restrictive. Linux Kernel/APR style
> > would be my preference, kicking us to 0.4.0 for everything from 0.3 / M3.
>
> Do we want to have the major version as zero? That implies to me that
> qpid is immature, which I would argue is not the case. The codebase
> has been evolving over the space of several years now and there are
> many production deployments of several components (e.g. I personally
> know about significant usage of the java broker and client).
>
> So I would suggest 1.4.0.
>
> RG
>

Re: M4 versioning and release management

[Rajith Attapattu <ra...@gmail.com>]

On Wed, Oct 8, 2008 at 10:04 AM, Aidan Skinner <ai...@apache.org> wrote:

> On Wed, Oct 8, 2008 at 2:57 PM, Rajith Attapattu <ra...@gmail.com>
> wrote:
>
> > Most incubator projects stick with milestone releases (Mx) until they
> > graduate.
>
> That doesn't seem to be the case currently. UIMA, empire-db, CouchDB,
> Pig, Buildr, Sling, Tuscany, Abdera, CXF all use numeric versions.
> Qpid is the only release from the incubator that I can see since May
> (when I gave up looking) that's used a milestone.


> > So as Alan points out we should reserve the 1.0 for our first release
> after
> > graduation.
>
> There's nothing in policy about that.
>
> > So we should definitely make use of that opportunity and stick with M4
> for
> > the next release.
>
> Except that it messes up autoconf so the cpp has an entirely different
> version from the other artifacts. It's generally a bit of a PITA.
>
> s/M/0./ seems simple, straightforward and easily for tooling. I'm
> amazed that it's generated this much discussion.


I agree with s/M/.0
Sorry didn't see that bit in the email thread:).


>
>
> - Aidan
> --
> Apache Qpid - World Domination through Advanced Message Queueing
> http://cwiki.apache.org/qpid
> "Nine-tenths of wisdom consists in being wise in time." - Theodore
> Roosevelt
>



-- 
Regards,

Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/

Re: M4 versioning and release management

[Aidan Skinner <ai...@apache.org>]

On Wed, Oct 8, 2008 at 2:57 PM, Rajith Attapattu <ra...@gmail.com> wrote:

> Most incubator projects stick with milestone releases (Mx) until they
> graduate.

That doesn't seem to be the case currently. UIMA, empire-db, CouchDB,
Pig, Buildr, Sling, Tuscany, Abdera, CXF all use numeric versions.
Qpid is the only release from the incubator that I can see since May
(when I gave up looking) that's used a milestone.

> So as Alan points out we should reserve the 1.0 for our first release after
> graduation.

There's nothing in policy about that.

> So we should definitely make use of that opportunity and stick with M4 for
> the next release.

Except that it messes up autoconf so the cpp has an entirely different
version from the other artifacts. It's generally a bit of a PITA.

s/M/0./ seems simple, straightforward and easily for tooling. I'm
amazed that it's generated this much discussion.

- Aidan
-- 
Apache Qpid - World Domination through Advanced Message Queueing
http://cwiki.apache.org/qpid
"Nine-tenths of wisdom consists in being wise in time." - Theodore Roosevelt

Re: M4 versioning and release management

[Rajith Attapattu <ra...@gmail.com>]

Most incubator projects stick with milestone releases (Mx) until they
graduate.
As Alan pointed out incubator projects are not considered matured (not
necessarily the code, but the community) and endorsed by the ASF.
That's the reason why we have to add the following disclaimer to our
releases.
https://svn.apache.org/repos/asf/incubator/qpid/trunk/qpid/DISCLAIMER

So as Alan points out we should reserve the 1.0 for our first release after
graduation.
A lot of the incubator projects make a lot of PR around the 1.0 release
after graduation.

So we should definitely make use of that opportunity and stick with M4 for
the next release.
I believe we are ready as community and could push for graduation soon, so
lets be patient with our versioning until then :).

Regards,

Rajith.


On Wed, Oct 8, 2008 at 8:48 AM, Alan Conway <ac...@redhat.com> wrote:

> On Tue, 2008-10-07 at 20:39 +0100, Robert Greig wrote:
> > 2008/10/7 Aidan Skinner <ai...@apache.org>:
> >
> > > The C++ requirements seem to be quite restrictive. Linux Kernel/APR
> style
> > > would be my preference, kicking us to 0.4.0 for everything from 0.3 /
> M3.
> >
> > Do we want to have the major version as zero? That implies to me that
> > qpid is immature, which I would argue is not the case. The codebase
> > has been evolving over the space of several years now and there are
> > many production deployments of several components (e.g. I personally
> > know about significant usage of the java broker and client).
> >
> > So I would suggest 1.4.0.
> >
> > RG
>
> As an Apache project we are not "mature" or "released" until we
> graduate. I'd be inclined to go with 0.4 and reserve 1.x for our first
> graduated release. If we go with 1.4 then our graduated releases will
> have to start at 2.0.
>
>
>
>


-- 
Regards,

Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/

Re: M4 versioning and release management

[Alan Conway <ac...@redhat.com>]

On Tue, 2008-10-07 at 20:39 +0100, Robert Greig wrote:
> 2008/10/7 Aidan Skinner <ai...@apache.org>:
> 
> > The C++ requirements seem to be quite restrictive. Linux Kernel/APR style
> > would be my preference, kicking us to 0.4.0 for everything from 0.3 / M3.
> 
> Do we want to have the major version as zero? That implies to me that
> qpid is immature, which I would argue is not the case. The codebase
> has been evolving over the space of several years now and there are
> many production deployments of several components (e.g. I personally
> know about significant usage of the java broker and client).
> 
> So I would suggest 1.4.0.
> 
> RG

As an Apache project we are not "mature" or "released" until we
graduate. I'd be inclined to go with 0.4 and reserve 1.x for our first
graduated release. If we go with 1.4 then our graduated releases will
have to start at 2.0.

Re: M4 versioning and release management

[Robert Greig <ro...@gmail.com>]

2008/10/7 Aidan Skinner <ai...@apache.org>:

> The C++ requirements seem to be quite restrictive. Linux Kernel/APR style
> would be my preference, kicking us to 0.4.0 for everything from 0.3 / M3.

Do we want to have the major version as zero? That implies to me that
qpid is immature, which I would argue is not the case. The codebase
has been evolving over the space of several years now and there are
many production deployments of several components (e.g. I personally
know about significant usage of the java broker and client).

So I would suggest 1.4.0.

RG

Re: M4 versioning and release management

[Aidan Skinner <ai...@apache.org>]

On Wed, Oct 8, 2008 at 11:56 AM, Gordon Sim <gs...@redhat.com> wrote:

> The last date I saw suggested for the freeze was the 22nd October. I've been
> working to that and this Friday would be a bit too early for me.

Ah. Must have missed that mail. That's cool. :)

- Aidan
-- 
Apache Qpid - World Domination through Advanced Message Queueing
http://cwiki.apache.org/qpid
"Nine-tenths of wisdom consists in being wise in time." - Theodore Roosevelt

Re: M4 versioning and release management

[Aidan Skinner <ai...@apache.org>]

On Wed, Oct 8, 2008 at 1:46 PM, Carl Trieloff <cc...@redhat.com> wrote:
> Gordon Sim wrote:
>>
>> Aidan Skinner wrote:
>>>
>>> On Tue, Oct 7, 2008 at 6:36 PM, Rafael Schloming <ra...@redhat.com>
>>> wrote:
>>>
>>>> I can't speak to the great version number debate, but I'm happy to
>>>> volunteer
>>>> for the release management this time around.
>>>
>>> Well done that man. Are we still freezing on Friday?
>>
>> The last date I saw suggested for the freeze was the 22nd October. I've
>> been working to that and this Friday would be a bit too early for me.
>
> I also need to the 22nd as discussed on a previous thread
> Carl.

That's cool with me. It would be good to have a clear schedule posted
up somewhere. :)

- Aidan
-- 
Apache Qpid - World Domination through Advanced Message Queueing
http://cwiki.apache.org/qpid
"Nine-tenths of wisdom consists in being wise in time." - Theodore Roosevelt

Re: M4 versioning and release management

[Carl Trieloff <cc...@redhat.com>]

Gordon Sim wrote:
> Aidan Skinner wrote:
>> On Tue, Oct 7, 2008 at 6:36 PM, Rafael Schloming <ra...@redhat.com> 
>> wrote:
>>
>>> I can't speak to the great version number debate, but I'm happy to 
>>> volunteer
>>> for the release management this time around.
>>
>> Well done that man. Are we still freezing on Friday?
>
> The last date I saw suggested for the freeze was the 22nd October. 
> I've been working to that and this Friday would be a bit too early for 
> me.

I also need to the 22nd as discussed on a previous thread
Carl.

Re: M4 versioning and release management

[Gordon Sim <gs...@redhat.com>]

Aidan Skinner wrote:
> On Tue, Oct 7, 2008 at 6:36 PM, Rafael Schloming <ra...@redhat.com> wrote:
> 
>> I can't speak to the great version number debate, but I'm happy to volunteer
>> for the release management this time around.
> 
> Well done that man. Are we still freezing on Friday?

The last date I saw suggested for the freeze was the 22nd October. I've 
been working to that and this Friday would be a bit too early for me.

Re: M4 versioning and release management

[Aidan Skinner <ai...@apache.org>]

On Tue, Oct 7, 2008 at 6:36 PM, Rafael Schloming <ra...@redhat.com> wrote:

> I can't speak to the great version number debate, but I'm happy to volunteer
> for the release management this time around.

Well done that man. Are we still freezing on Friday?

- Aidan
-- 
Apache Qpid - World Domination through Advanced Message Queueing
http://cwiki.apache.org/qpid
"Nine-tenths of wisdom consists in being wise in time." - Theodore Roosevelt

Re: M4 versioning and release management

[Rafael Schloming <ra...@redhat.com>]

Aidan Skinner wrote:
> Two things about our next release. Firstly, who is going to release manage
> it? I am going to be away for chunks of critical time so won't be able to do
> it this time round.
> 
> Secondly, and possibly more contraversially, what shall we do about version
> numbers? Having everything using the same version would be quite good.
> 
> The C++ requirements seem to be quite restrictive. Linux Kernel/APR style
> would be my preference, kicking us to 0.4.0 for everything from 0.3 / M3.

I can't speak to the great version number debate, but I'm happy to 
volunteer for the release management this time around.

--Rafael