Hi Justin I'm in agreement with the plan to reorganise the source tree in the way you describe (and expect that we would want a similar change for java) but am I concerned about the timing of such a big change. We should be reorganising trunk just *after* a release branch to give us plenty of time to work through the inevitable unexpected consequences properly.
I am in favour of having one more qpid-wide release (and I would suggest we stick with our existing numbering scheme i.e. 0.32), then split the source tree and adopt the new numbering convention for the next -modular- releases. Thoughts? cheers, Keith. On 21 January 2015 at 12:35, Justin Ross <justin.r...@gmail.com> wrote: > Hi, Keith. > > Apart from picking an approach for version numbers, I don't think there is > anything that should prevent you from starting an independent Java release. > > I've put some of my thoughts regarding source-tree organization down in > the wiki. Please feel free to add your own. > > > https://cwiki.apache.org/confluence/display/qpid/Source+tree+layout+proposal > > Whatever we decide on, we don't have to do it all at once in a big bang. > We can incrementally move modules into a new structure. > > Justin > > > On Fri, Jan 9, 2015 at 4:34 AM, Keith W <keith.w...@gmail.com> 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 <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 >> > >> > >> > >
