qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Ross <justin.r...@gmail.com>
Subject Re: Any ETA on a QPid 0.32 release
Date Tue, 27 Jan 2015 17:21:45 GMT
Based on what we've discussed so far, here's what I propose:

We prepare one more cross-component Qpid release, 0.32.  This time, the
components share a version number and a source branch.  Next time they
won't.

I'll manage the C++, Python, and related components.  I will leave the Java
component to Keith or whoever elects to take it on.

After we branch for Beta, we'll start to reorganize the source tree for
independent releases.

For reasons of continuity, the next C++ and Python releases will use the
version number "33", without the leading "0.".

For 0.32, I'd like to try to stick with the schedule I posted earlier: end
of this month for Alpha, and middle of February for Beta.

Justin

On Tue, Jan 27, 2015 at 5:46 AM, Rob Godfrey <rob.j.godfrey@gmail.com>
wrote:

> I strongly agree with Keith that any change to the source tree should
> happen (immediately) after (branching for) the next release.  We can have
> separate people managing the different components if we like, but I think
> for this release we would be looking at a single release date and running
> the existing release scripts.  After this release we can work out exactly
> how we want to release each component separately.
>
> In terms of numbering, I'm relatively relaxed as to whether we change now
> or at the next release - I don't think the two changes have to be
> coincident.
>
> As an aside, in terms of release numbering, somewhat coincidentally this
> will be (if I have calculated this correctly) the 15th release of Qpid
> since graduation (the first release was 0.5, then 0.6 and thereafter we
> always incremented by 0.2), so calling this release 15.1 (as the first
> release after an arbitrary rebasing of the version numbers) would be fine
> by me :-)
>
> -- Rob
>
> On 23 January 2015 at 15:54, Keith W <keith.wall@gmail.com> wrote:
>
>> Hi Justin
>>
>> I'm in agreement with the plan to reorganise the source tree in the way
>> you
>> describe (and expect that we would want a similar change for java) but am
>> I
>> concerned about the timing of such a big change.    We should be
>> reorganising trunk just *after* a release branch to give us plenty of time
>> to work through the inevitable unexpected consequences properly.
>>
>> I am in favour of having one more qpid-wide release (and I would suggest
>> we
>> stick with our existing numbering scheme i.e. 0.32), then split the source
>> tree and adopt the new numbering convention for the next -modular-
>> releases.
>>
>> Thoughts?
>>
>> cheers, Keith.
>>
>>
>>
>>
>> On 21 January 2015 at 12:35, Justin Ross <justin.ross@gmail.com> wrote:
>>
>> > Hi, Keith.
>> >
>> > Apart from picking an approach for version numbers, I don't think there
>> is
>> > anything that should prevent you from starting an independent Java
>> release.
>> >
>> > I've put some of my thoughts regarding source-tree organization down in
>> > the wiki.  Please feel free to add your own.
>> >
>> >
>> >
>> https://cwiki.apache.org/confluence/display/qpid/Source+tree+layout+proposal
>> >
>> > Whatever we decide on, we don't have to do it all at once in a big bang.
>> > We can incrementally move modules into a new structure.
>> >
>> > Justin
>> >
>> >
>> > On Fri, Jan 9, 2015 at 4:34 AM, Keith W <keith.wall@gmail.com> wrote:
>> >
>> >> Hi all,
>> >>
>> >> Looking through this thread, it is not clear that we came to a settled
>> >> position for release numbering, and when exactly we'd would move to
>> >> releasing components independently.   On the java side we are getting
>> to a
>> >> position where a release soon would be sensible.  How best do we go
>> >> forward?
>> >>
>> >> I'll be ready to put in some time helping plan/make the changes to the
>> >> release system happen, once we agree what that direction should be.
>> >>
>> >> Kind regards, Keith.
>> >>
>> >>
>> >>
>> >> On 3 December 2014 at 15:15, Robbie Gemmell <robbie.gemmell@gmail.com>
>> >> wrote:
>> >>
>> >> > In addition to [point] releases not actually occuring at the time the
>> >> > version suggests, for me another downside of using the Year.Month
>> >> > approach is that it doesnt as clearly convey a sense of impact for
>> the
>> >> > changes involved in the release, i.e is it a major or minor release,
>> >> > are there any compatibility considerations etc. It might for a bugfix
>> >> > release, e.g 15.1.1 vs 15.1, however should 16.1 be expected to be
>> >> > majorly different than 15.12 or not, given it might have nearly 2
>> >> > months of changes in it, or possibly just days?  If it isnt,
>> >> > could/should it have been labeled 15.12.1 instead (at which point,
>> >> > back to that naming vs timing issue)? Obviously we dont convey that
>> >> > sort of information with the current versions, but it would be nice
>> to
>> >> > start.
>> >> >
>> >> > The major example of Year.Month naming that springs to mind for me
is
>> >> > Ubuntu, which isnt really quite the same situations since their
>> >> > releases are mostly a distribution of other components, whicht are
>> all
>> >> > versioned independently and can often be updated to an extent between
>> >> > the containing Year.Month distribution releases. I can't immediately
>> >> > think of seeing any Apache projects using it as a convention, but I
>> >> > assume there are some.
>> >> >
>> >> > Robbie
>> >> >
>> >> > On 3 December 2014 at 11:50, Rob Godfrey <rob.j.godfrey@gmail.com>
>> >> wrote:
>> >> > > Agreed - we'd use target date.
>> >> > >
>> >> > > To Robbie's earlier comment on point releases, we (Java side)
might
>> >> then
>> >> > > subsequently release a 15.1.1 as a bugfix release of 15.1, where
>> the
>> >> next
>> >> > > scheduled release would be a 15.5 or whatever (ideally on the
java
>> >> side I
>> >> > > think we'd like to move to more frequent releases, but that's
a
>> >> separate
>> >> > > issue).
>> >> > >
>> >> > > -- Rob
>> >> > >
>> >> > > On 3 December 2014 at 12:21, Gordon Sim <gsim@redhat.com>
wrote:
>> >> > >
>> >> > >> On 12/03/2014 11:02 AM, Justin Ross wrote:
>> >> > >>
>> >> > >>> On Wed, Dec 3, 2014 at 5:00 AM, Gordon Sim <gsim@redhat.com>
>> wrote:
>> >> > >>>
>> >> > >>>  On 12/02/2014 09:59 PM, Chuck Rolke wrote:
>> >> > >>>>
>> >> > >>>>  I feel like for qpidd and qpid::messaging at least,
a '1.0' at
>> >> this
>> >> > >>>>>
>> >> > >>>>>> point is meaningless and even perhaps confusing.
They are both
>> >> well
>> >> > >>>>>> past
>> >> > >>>>>> that really, placing a high priority on stability
and backward
>> >> > >>>>>> compatibility. The 1.0 label to me is more
appropriate for
>> newer
>> >> > >>>>>> components like proton, dispatch-router and
the new JMS
>> client.
>> >> > >>>>>>
>> >> > >>>>>>
>> >> > >>>>> There's a certain appeal to having the version
number be the
>> >> > year.month
>> >> > >>>>> that the product was branched especially if we
have four or
>> five
>> >> > >>>>> closely related products. If some whizzy feature
of the broker
>> >> > >>>>> is released in 15.4 then you know that it probably
isn't
>> >> supported in
>> >> > >>>>> dispatch 15.2. There's no way to know that if
the broker is 3.2
>> >> and
>> >> > >>>>> dispatch is 1.1.
>> >> > >>>>>
>> >> > >>>>>
>> >> > >>>> Yes, I can see the value in being able to easily determine
>> ordering
>> >> > >>>> between release numbers of components on different
schedules.
>> >> Also, it
>> >> > >>>> may
>> >> > >>>> help force a more public schedule, by setting the
target date in
>> >> > order to
>> >> > >>>> determine the next release number.
>> >> > >>>>
>> >> > >>>
>> >> > >>>
>> >> > >>> I like the idea, but I think it would be "unstable". 
During the
>> >> > release
>> >> > >>> process, we'd have to talk about 15.next or something
like that
>> >> because
>> >> > >>> it's too hard to know exactly which month we will finish.
 "3.2"
>> >> would
>> >> > be
>> >> > >>> easier to talk about with precision.
>> >> > >>>
>> >> > >>
>> >> > >> I think you would use the target date, not the actual date.
So
>> 15.1
>> >> > might
>> >> > >> actually not be ready until february, but you wouldn't change
the
>> >> > release
>> >> > >> number. Otherwise I would agree with you it would be too fluid.
>> >> > >>
>> >> > >>
>> >> > >>
>> >> > >>
>> ---------------------------------------------------------------------
>> >> > >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> > >> For additional commands, e-mail: users-help@qpid.apache.org
>> >> > >>
>> >> > >>
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> > For additional commands, e-mail: users-help@qpid.apache.org
>> >> >
>> >> >
>> >>
>> >
>> >
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message