qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith W <keith.w...@gmail.com>
Subject Re: Any ETA on a QPid 0.32 release
Date Wed, 28 Jan 2015 08:45:14 GMT
Justin,

That all sounds sensible to me.

Once the 0.32 cross-component  release is done, I am happy to take on the
release manager role of the Java components.

cheers, Keith



On 27 January 2015 at 17:21, Justin Ross <justin.ross@gmail.com> wrote:

> 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