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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> wrote: > > > > > >> On 12/03/2014 11:02 AM, Justin Ross wrote: > > >> > > >>> On Wed, Dec 3, 2014 at 5:00 AM, Gordon Sim <[email protected]> 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: [email protected] > > >> For additional commands, e-mail: [email protected] > > >> > > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
