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, 09 Jan 2015 09:34:57 GMT
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