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 > >
