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]
