Justin, That all sounds sensible to me.
Once the 0.32 cross-component release is done, I am happy to take on the release manager role of the Java components. cheers, Keith On 27 January 2015 at 17:21, Justin Ross <justin.r...@gmail.com> wrote: > Based on what we've discussed so far, here's what I propose: > > We prepare one more cross-component Qpid release, 0.32. This time, the > components share a version number and a source branch. Next time they > won't. > > I'll manage the C++, Python, and related components. I will leave the > Java component to Keith or whoever elects to take it on. > > After we branch for Beta, we'll start to reorganize the source tree for > independent releases. > > For reasons of continuity, the next C++ and Python releases will use the > version number "33", without the leading "0.". > > For 0.32, I'd like to try to stick with the schedule I posted earlier: end > of this month for Alpha, and middle of February for Beta. > > Justin > > On Tue, Jan 27, 2015 at 5:46 AM, Rob Godfrey <rob.j.godf...@gmail.com> > wrote: > >> I strongly agree with Keith that any change to the source tree should >> happen (immediately) after (branching for) the next release. We can have >> separate people managing the different components if we like, but I think >> for this release we would be looking at a single release date and running >> the existing release scripts. After this release we can work out exactly >> how we want to release each component separately. >> >> In terms of numbering, I'm relatively relaxed as to whether we change now >> or at the next release - I don't think the two changes have to be >> coincident. >> >> As an aside, in terms of release numbering, somewhat coincidentally this >> will be (if I have calculated this correctly) the 15th release of Qpid >> since graduation (the first release was 0.5, then 0.6 and thereafter we >> always incremented by 0.2), so calling this release 15.1 (as the first >> release after an arbitrary rebasing of the version numbers) would be fine >> by me :-) >> >> -- Rob >> >> On 23 January 2015 at 15:54, Keith W <keith.w...@gmail.com> wrote: >> >>> 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 >>> >> > >>> >> > >>> >> >>> > >>> > >>> >> >> >
