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.gemm...@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.godf...@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 <g...@redhat.com> wrote: > > > >> On 12/03/2014 11:02 AM, Justin Ross wrote: > >> > >>> On Wed, Dec 3, 2014 at 5:00 AM, Gordon Sim <g...@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-unsubscr...@qpid.apache.org > >> For additional commands, e-mail: users-h...@qpid.apache.org > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > >
