You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Rajith Attapattu <ra...@gmail.com> on 2007/03/06 17:40:44 UTC
Release Plan for post M2
Folks,
I think it's a good time to get the ball rolling on the release plan for
post M2.
Here are some suggestions to start of with.
Visioning:
I suggest to move away from Mx (or milestones) releases and use a numbering
scheme like 0.9x.x.
We could call the next release 0.90 and the subsequent releases as 0.91,
0.92 ..etc
If we need to make bug fixes/updates to an existing release we can do an
interim release like 0.91.1, 0.91.2 etc
Release Plan:
We need to make a release plan for each artifact (linked to the main release
page) and clearly capture what we are going to deliver.
This kind of visibility/planning is important for qpid users (and also to
committers/contributors) to plan their development.
Road Map :
We need to have a road map to provide visibility and to communicate clearly
to the qpid users our forward thinking about the project.
It also helps us as a community to agree and be responsible for the vision
and goals of the project.
The bigger picture can be linked to release plans to communicate how we
intend to realize the road map.
We could add notes and status reports to provide interim status.
Suggestions are most welcomed.
Regards,
Rajith
Re: [VOTE] Versioning proposal.
Posted by Robert Godfrey <ro...@gmail.com>.
I guess I should say something like
+ 1.0-0.0
Got to admit, deciding on version numbering schemes isn't one of those
things that gets me excited... the reasoning seems good to me (aiming for a
1.0 release) let's see if anyone has any objections...
-- Rob
On 07/03/07, Alan Conway <ac...@redhat.com> wrote:
>
> [ ] Vote to accept the following versioning proposal.
>
> Gee, my first call for a vote :)
>
> I have a proposal that I think satisfies Apache, Fedora (and RPM
> generally), the desire to show we're nearing release and the desire to
> avoid choosing version numbers at random.
>
> Apache considers M numbers to be pre-release indicators, much like alpha
> or beta. So we can say qpid is version 1.0 pre-release M2, meaning we're
> approaching the real 1.0 release, and this is the second incubator
> pre-release.
>
> RPM wants <name>-<version>-<release>, and non-numerics are allowed in
> the release field providing we give RPM a little help to figure out the
> order, so it would be:
> qpid-1.0-0.2.incubating-M2
> Which means qpid version 1.0, second incubator pre-release (the extra
> 0.2 is so RPM doesn't have to parse "incubating-M2")
>
> When we get to the real 1.0 release the RPM becomes:
> qpid-1.0-1
>
> Meaning: qpid 1.0 first real release. RPM will consider this newer than
> all the 1.0-0.blah incubator releases.
>
> Cheers,
> Alan.
>
Re: [VOTE] Versioning proposal.
Posted by Rajith Attapattu <ra...@gmail.com>.
On 3/12/07, Alan Conway <ac...@redhat.com> wrote:
>
> Rajith Attapattu wrote:
> > same with me.
> > My original email about the whole thing was to make the RPM thingy
> > more easy
> > and also to make a more smooth transition to a 1.0 release.
> > I guess we probably have to wait till we graduate to shake off that
> > "incubating" part from the version name. (it looks ugly)
> >
> > I agree with Alans propsal until we graduate, and then we can do a
> > bunch of
> > 0.9x releases culminating in a 1.0 release.
> My proposal was to use 1.0-0.n.incubating-Mn for the nth incubator
> pre-release and 1.0-1 for our first "real" 1.0 out-of-incubator
> release. Do you think we won't be ready for a 1.0 release at the point
> we leave the incubator?
Ok I got it.
I think atleast on the java side we are ready to do a real 1.0 release when
we graduate.
I am sure the others (c+++,python, ruby) will be ready too.
Rajith
Here's the proposal again:
> > I have a proposal that I think satisfies Apache, Fedora (and RPM
> > generally), the desire to show we're nearing release and the desire to
> > avoid choosing version numbers at random.
> >
> > Apache considers M numbers to be pre-release indicators, much like
> > alpha or beta. So we can say qpid is version 1.0 pre-release M2,
> > meaning we're approaching the real 1.0 release, and this is the second
> > incubator pre-release.
> >
> > RPM wants <name>-<version>-<release>, and non-numerics are allowed in
> > the release field providing we give RPM a little help to figure out
> > the order, so it would be:
> > qpid-1.0-0.2.incubating-M2
> > Which means qpid version 1.0, second incubator pre-release (the extra
> > 0.2 is so RPM doesn't have to parse "incubating-M2")
> >
> > When we get to the real 1.0 release the RPM becomes:
> > qpid-1.0-1
> >
> > Meaning: qpid 1.0 first real release. RPM will consider this newer
> > than all the 1.0-0.blah incubator releases.
>
> Cheers,
> Alan.
>
Re: [VOTE] Versioning proposal.
Posted by Alan Conway <ac...@redhat.com>.
Rajith Attapattu wrote:
> same with me.
> My original email about the whole thing was to make the RPM thingy
> more easy
> and also to make a more smooth transition to a 1.0 release.
> I guess we probably have to wait till we graduate to shake off that
> "incubating" part from the version name. (it looks ugly)
>
> I agree with Alans propsal until we graduate, and then we can do a
> bunch of
> 0.9x releases culminating in a 1.0 release.
My proposal was to use 1.0-0.n.incubating-Mn for the nth incubator
pre-release and 1.0-1 for our first "real" 1.0 out-of-incubator
release. Do you think we won't be ready for a 1.0 release at the point
we leave the incubator?
Here's the proposal again:
> I have a proposal that I think satisfies Apache, Fedora (and RPM
> generally), the desire to show we're nearing release and the desire to
> avoid choosing version numbers at random.
>
> Apache considers M numbers to be pre-release indicators, much like
> alpha or beta. So we can say qpid is version 1.0 pre-release M2,
> meaning we're approaching the real 1.0 release, and this is the second
> incubator pre-release.
>
> RPM wants <name>-<version>-<release>, and non-numerics are allowed in
> the release field providing we give RPM a little help to figure out
> the order, so it would be:
> qpid-1.0-0.2.incubating-M2
> Which means qpid version 1.0, second incubator pre-release (the extra
> 0.2 is so RPM doesn't have to parse "incubating-M2")
>
> When we get to the real 1.0 release the RPM becomes:
> qpid-1.0-1
>
> Meaning: qpid 1.0 first real release. RPM will consider this newer
> than all the 1.0-0.blah incubator releases.
Cheers,
Alan.
Re: [VOTE] Versioning proposal.
Posted by Rajith Attapattu <ra...@gmail.com>.
same with me.
My original email about the whole thing was to make the RPM thingy more easy
and also to make a more smooth transition to a 1.0 release.
I guess we probably have to wait till we graduate to shake off that
"incubating" part from the version name. (it looks ugly)
I agree with Alans propsal until we graduate, and then we can do a bunch of
0.9x releases culminating in a 1.0 release.
Rajith
On 3/8/07, Gordon Sim <gs...@redhat.com> wrote:
>
> > [+1] Vote to accept the following versioning proposal.
>
> fine by me
>
Re: [VOTE] Versioning proposal.
Posted by Alan Conway <ac...@redhat.com>.
Rupert Smith wrote:
> [+1] So in maven its, 1.0-0.2.incubating-M2-SNAPSHOT (now thats a
> catchy version number!)
Maven can just use 1.0.incubating-M2. The extra -0.2 is a redundant
repetition of the 2 from M2 to help RPM get version comparisons right,
we don't have to inflict it everywhere.
Cheers,
Alan.
Re: [VOTE] Versioning proposal.
Posted by Rupert Smith <ru...@googlemail.com>.
[+1] So in maven its, 1.0-0.2.incubating-M2-SNAPSHOT (now thats a
catchy version number!)
On 3/8/07, Martin Ritchie <ri...@apache.org> wrote:
> [+1] Vote to accept the following versioning proposal.
>
> --
> Martin Ritchie
>
Re: [VOTE] Versioning proposal.
Posted by Martin Ritchie <ri...@apache.org>.
[+1] Vote to accept the following versioning proposal.
--
Martin Ritchie
Re: [VOTE] Versioning proposal.
Posted by Gordon Sim <gs...@redhat.com>.
> [+1] Vote to accept the following versioning proposal.
fine by me
[VOTE] Versioning proposal.
Posted by Alan Conway <ac...@redhat.com>.
[ ] Vote to accept the following versioning proposal.
Gee, my first call for a vote :)
I have a proposal that I think satisfies Apache, Fedora (and RPM
generally), the desire to show we're nearing release and the desire to
avoid choosing version numbers at random.
Apache considers M numbers to be pre-release indicators, much like alpha
or beta. So we can say qpid is version 1.0 pre-release M2, meaning we're
approaching the real 1.0 release, and this is the second incubator
pre-release.
RPM wants <name>-<version>-<release>, and non-numerics are allowed in
the release field providing we give RPM a little help to figure out the
order, so it would be:
qpid-1.0-0.2.incubating-M2
Which means qpid version 1.0, second incubator pre-release (the extra
0.2 is so RPM doesn't have to parse "incubating-M2")
When we get to the real 1.0 release the RPM becomes:
qpid-1.0-1
Meaning: qpid 1.0 first real release. RPM will consider this newer than
all the 1.0-0.blah incubator releases.
Cheers,
Alan.
Re: Release Plan for post M2
Posted by Rajith Attapattu <ra...@gmail.com>.
Thanks John for the comments, appreciate it.
Let me capture this on a wiki page and then hopefully others can also add to
it.
We can also have a wish list to add the nice to haves, but as u said it's
important to agree on the "must haves" and defined plan on how to achive
them. Once I create the wiki page I will start a separate thread on road map
to give it the attention it deserves.
Regards,
Rajith
On 3/12/07, John O'Hara <jo...@gmail.com> wrote:
>
> Ah - its good to see the real reason is RPM versioning, which is fine.
>
> I'm +1 for having Mx and translate this mechanically to some RPM version.
> But don't make the version numbers rise too fast, and don't start too
> high.
> We will regret that.
> In some ways, getting a "build number" in would be nice too but maybe too
> early.
>
> As regards roadmaps and users - I'd just like to say we're using this
> quite
> heavily; some discussion around roadmaps would be good. We need to keep
> things real, and grounded. Sometimes developers forget the difference
> between must haves and nice to haves.
>
> For me:
> - Posix ACLs' on Queues (or whatever the right model is)
> - Good TX performance
> - Good, portable management between the Java/C++ brokers
> - Understand the multicast mapping (and propose back to the WG)
>
> Lets get the basics really good.
> John
>
> On 07/03/07, David Lutterkort <dl...@redhat.com> wrote:
> >
> > On Wed, 2007-03-07 at 14:50 -0500, Alan Conway wrote:
> > > For RPM purposes we need to use the simple numeric version.release up
> > > front so rpm can figure out the ordering, but I think we can safely
> add
> > > a decorator to meet the apache requirement (RPM experts can you
> > > confirm? I checked the rpm source code and it appears that RPM will
> stop
> > > at the first differing segment so e.g. 0.2-incubatingM2 is older than
> > 0.3)
> > >
> > > So the RPM versions would be:
> > > 0.1-incubating-M1
> > > 0.2-incubating-M2 (or 0.9-incubating-M2 or 0.9-incubating-M9 at our
> > whim)
> > > etc. till we leave incubator and go to 1.0 etc.
> > >
> > > It would be simplest to have a straightforward correspondence between
> > > 0.x and Mx but they don't have to be related provided they both
> increase
> > > monotonically on every release.
> >
> > I can't say much about Apache's versioning requirements; the Fedora
> > guidelines [1] have some info on the subject.
> >
> > If you install 'rpmdevtools', you can use fedora-rpmvercmp to test how
> > various versions will get ordered. In general, things are a little
> > simpler if the version/release are made up of numbers and '.' only,
> > though there are cases where the version/release have additional 'stuff'
> > embedded in them.
> >
> > David
> >
> > [1]
> >
> >
> http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-18aa467fc6925455e44be682fd336667a17e8933
> >
> >
>
Re: Release Plan for post M2
Posted by John O'Hara <jo...@gmail.com>.
Ah - its good to see the real reason is RPM versioning, which is fine.
I'm +1 for having Mx and translate this mechanically to some RPM version.
But don't make the version numbers rise too fast, and don't start too high.
We will regret that.
In some ways, getting a "build number" in would be nice too but maybe too
early.
As regards roadmaps and users - I'd just like to say we're using this quite
heavily; some discussion around roadmaps would be good. We need to keep
things real, and grounded. Sometimes developers forget the difference
between must haves and nice to haves.
For me:
- Posix ACLs' on Queues (or whatever the right model is)
- Good TX performance
- Good, portable management between the Java/C++ brokers
- Understand the multicast mapping (and propose back to the WG)
Lets get the basics really good.
John
On 07/03/07, David Lutterkort <dl...@redhat.com> wrote:
>
> On Wed, 2007-03-07 at 14:50 -0500, Alan Conway wrote:
> > For RPM purposes we need to use the simple numeric version.release up
> > front so rpm can figure out the ordering, but I think we can safely add
> > a decorator to meet the apache requirement (RPM experts can you
> > confirm? I checked the rpm source code and it appears that RPM will stop
> > at the first differing segment so e.g. 0.2-incubatingM2 is older than
> 0.3)
> >
> > So the RPM versions would be:
> > 0.1-incubating-M1
> > 0.2-incubating-M2 (or 0.9-incubating-M2 or 0.9-incubating-M9 at our
> whim)
> > etc. till we leave incubator and go to 1.0 etc.
> >
> > It would be simplest to have a straightforward correspondence between
> > 0.x and Mx but they don't have to be related provided they both increase
> > monotonically on every release.
>
> I can't say much about Apache's versioning requirements; the Fedora
> guidelines [1] have some info on the subject.
>
> If you install 'rpmdevtools', you can use fedora-rpmvercmp to test how
> various versions will get ordered. In general, things are a little
> simpler if the version/release are made up of numbers and '.' only,
> though there are cases where the version/release have additional 'stuff'
> embedded in them.
>
> David
>
> [1]
>
> http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-18aa467fc6925455e44be682fd336667a17e8933
>
>
Re: Release Plan for post M2
Posted by David Lutterkort <dl...@redhat.com>.
On Wed, 2007-03-07 at 14:50 -0500, Alan Conway wrote:
> For RPM purposes we need to use the simple numeric version.release up
> front so rpm can figure out the ordering, but I think we can safely add
> a decorator to meet the apache requirement (RPM experts can you
> confirm? I checked the rpm source code and it appears that RPM will stop
> at the first differing segment so e.g. 0.2-incubatingM2 is older than 0.3)
>
> So the RPM versions would be:
> 0.1-incubating-M1
> 0.2-incubating-M2 (or 0.9-incubating-M2 or 0.9-incubating-M9 at our whim)
> etc. till we leave incubator and go to 1.0 etc.
>
> It would be simplest to have a straightforward correspondence between
> 0.x and Mx but they don't have to be related provided they both increase
> monotonically on every release.
I can't say much about Apache's versioning requirements; the Fedora
guidelines [1] have some info on the subject.
If you install 'rpmdevtools', you can use fedora-rpmvercmp to test how
various versions will get ordered. In general, things are a little
simpler if the version/release are made up of numbers and '.' only,
though there are cases where the version/release have additional 'stuff'
embedded in them.
David
[1]
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-18aa467fc6925455e44be682fd336667a17e8933
Re: Release Plan for post M2
Posted by Alan Conway <ac...@redhat.com>.
Re version numbers and RPM versions etc. I have a proposal.
Daniel Kulp wrote:
> On Tuesday 06 March 2007 17:15, Alan Conway wrote:
>
>> On Tue, 2007-03-06 at 17:03 -0500, Daniel Kulp wrote:
>>
>>> Just FYI: that needs to be changed before the release. If the
>>> artifact doesn't have "incubator" in the name, it will get a "-1".
>>> That's the main reason the maven versions are all "1.0-incubating-M2".
I'd like to propose that we adopt a numeric "logical" version.release
scheme for all releases but also designate them by an apache M number.
So M1 == 0.1, M2 == 0.2 (or 0.9 if we want to play games) etc. Once we
get out of incubator we drop the M numbers and continue the simple
version.release numbering.
For RPM purposes we need to use the simple numeric version.release up
front so rpm can figure out the ordering, but I think we can safely add
a decorator to meet the apache requirement (RPM experts can you
confirm? I checked the rpm source code and it appears that RPM will stop
at the first differing segment so e.g. 0.2-incubatingM2 is older than 0.3)
So the RPM versions would be:
0.1-incubating-M1
0.2-incubating-M2 (or 0.9-incubating-M2 or 0.9-incubating-M9 at our whim)
etc. till we leave incubator and go to 1.0 etc.
It would be simplest to have a straightforward correspondence between
0.x and Mx but they don't have to be related provided they both increase
monotonically on every release.
Cheers,
Alan.
Re: Release Plan for post M2
Posted by Daniel Kulp <da...@iona.com>.
Alan,
On Tuesday 06 March 2007 16:50, Alan Conway wrote:
> On Tue, 2007-03-06 at 12:14 -0500, Rajith Attapattu wrote:
> > > I suggest we don't get to caught up in the nomeclature of our
> > > releases. Moving to a numbering scheme similar to AMQP is perhaps a
> > > reasonable approach. We started using Mx as that is the Incubator
> > > way.
>
> +1 on not getting caught up.
>
> For RPM numbering so I simply translated M1 to 0.1 so we currently have
> qpidc-0.1-4.src.rpm. This works if we want to continue Mn milestones for
> a while.
Just FYI: that needs to be changed before the release. If the artifact
doesn't have "incubator" in the name, it will get a "-1". That's the
main reason the maven versions are all "1.0-incubating-M2".
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: Release Plan for post M2
Posted by Alan Conway <ac...@redhat.com>.
On Tue, 2007-03-06 at 12:14 -0500, Rajith Attapattu wrote:
> > I suggest we don't get to caught up in the nomeclature of our
> > releases. Moving to a numbering scheme similar to AMQP is perhaps a
> > reasonable approach. We started using Mx as that is the Incubator way.
+1 on not getting caught up.
For RPM numbering so I simply translated M1 to 0.1 so we currently have
qpidc-0.1-4.src.rpm. This works if we want to continue Mn milestones for
a while.
Beyond that I would strongly advocate a simple dot-separated-integer
increment-by-one scheme. RPM uses <version>.<release>, GNU uses
<version>.<release>.<minor>. Either is fine with me. It scales to
unbounded numbers of versions and releases and has been tried and tested
over years of development on thousands of projects.
If we really must start higher than 0.1 then so be it, but 0.90 implies
we've done 90 releases which is a bit silly. We could start at 0.9,
making the next release 0.10. Note the "." in version numbers **is not a
decimal point**. 0.01 and 0.1 are the same version and 0.10 is higher
than 0.9.
I will say no more on the topic unless people start advocating some
lunatic scheme that would defeat RPMs version comparison algorithm.
Cheers,
Alan.
Re: Release Plan for post M2
Posted by Rajith Attapattu <ra...@gmail.com>.
On 3/6/07, Martin Ritchie <ri...@apache.org> wrote:
>
> On 06/03/07, Rajith Attapattu <ra...@gmail.com> wrote:
> > Folks,
> >
> > I think it's a good time to get the ball rolling on the release plan for
> > post M2.
> > Here are some suggestions to start of with.
> >
> > Visioning:
> > I suggest to move away from Mx (or milestones) releases and use a
> numbering
> > scheme like 0.9x.x.
> > We could call the next release 0.90 and the subsequent releases as 0.91,
> > 0.92 ..etc
> > If we need to make bug fixes/updates to an existing release we can do an
> > interim release like 0.91.1, 0.91.2 etc
>
> I suggest we don't get to caught up in the nomeclature of our
> releases. Moving to a numbering scheme similar to AMQP is perhaps a
> reasonable approach. We started using Mx as that is the Incubator way.
Here are the reasons
a) For RPM packaging the numbering scheme works well than the Mx stuff.
Infact the Mx stuff causes some issues for our packaging effort.
b) 0.9x releases gives the impression that we are closer to a 1.0 release
and the truth is we do want to graduate soon and do a 1.0 release.
c) AFAIK Mx is not a hard requitment for incubating projects.
> Release Plan:
> > We need to make a release plan for each artifact (linked to the main
> release
> > page) and clearly capture what we are going to deliver.
> > This kind of visibility/planning is important for qpid users (and also
> to
> > committers/contributors) to plan their development.
>
> I think if we are now targeting a user base then we need to have a user
> list.
Yes a user list might be helpful at some point.
But whether we have a user list or not, I think we need to plan for a user
base.
A release plan and a road map is still important for proper communication
among the qpid community.
Also in order to attract users to our project we need to clearly communicate
what our forward thinking is.
> Road Map :
> > We need to have a road map to provide visibility and to communicate
> clearly
> > to the qpid users our forward thinking about the project.
> > It also helps us as a community to agree and be responsible for the
> vision
> > and goals of the project.
> > The bigger picture can be linked to release plans to communicate how we
> > intend to realize the road map.
> > We could add notes and status reports to provide interim status.
> >
> > Suggestions are most welcomed.
> >
> > Regards,
> >
> > Rajith
>
>
>
> --
> Martin Ritchie
>
Re: Release Plan for post M2
Posted by Martin Ritchie <ri...@apache.org>.
On 06/03/07, Rajith Attapattu <ra...@gmail.com> wrote:
> Folks,
>
> I think it's a good time to get the ball rolling on the release plan for
> post M2.
> Here are some suggestions to start of with.
>
> Visioning:
> I suggest to move away from Mx (or milestones) releases and use a numbering
> scheme like 0.9x.x.
> We could call the next release 0.90 and the subsequent releases as 0.91,
> 0.92 ..etc
> If we need to make bug fixes/updates to an existing release we can do an
> interim release like 0.91.1, 0.91.2 etc
I suggest we don't get to caught up in the nomeclature of our
releases. Moving to a numbering scheme similar to AMQP is perhaps a
reasonable approach. We started using Mx as that is the Incubator way.
> Release Plan:
> We need to make a release plan for each artifact (linked to the main release
> page) and clearly capture what we are going to deliver.
> This kind of visibility/planning is important for qpid users (and also to
> committers/contributors) to plan their development.
I think if we are now targeting a user base then we need to have a user list.
> Road Map :
> We need to have a road map to provide visibility and to communicate clearly
> to the qpid users our forward thinking about the project.
> It also helps us as a community to agree and be responsible for the vision
> and goals of the project.
> The bigger picture can be linked to release plans to communicate how we
> intend to realize the road map.
> We could add notes and status reports to provide interim status.
>
> Suggestions are most welcomed.
>
> Regards,
>
> Rajith
--
Martin Ritchie