qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Godfrey <rob.j.godf...@gmail.com>
Subject Re: Any ETA on a QPid 0.32 release
Date Thu, 15 Jan 2015 10:12:12 GMT
Justin,

do you have proposed dates for 0.32 alpha/beta/release?  It would be good
to get another release out soon.

-- Rob

On 9 January 2015 at 10:34, 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