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 Fri, 23 Jan 2015 14:54:43 GMT
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