Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (athena.apache.org: domain of rob.j.godfrey@gmail.com
 designates 209.85.192.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAFEMS4uh_c0ro=VALtybdZ1T-AiG7CK_CWU1wPpE7wxeRy2P_g@mail.gmail.com>
References: <547CE797.9060108@gmail.com>
	<CAFitrpQQtcy7b4WrKyoQBMhPo7eToJ3zPUg74Z53Px4rZq8m8w@mail.gmail.com>
	<CACsaS944g8RsHGZnf=0w3qZSt4ea6O-DwH5+EECGb2z4bZL8JQ@mail.gmail.com>
	<CAFitrpSs0+gRBp8naMaijETivrgjOVKARpBDsC9M3ySb13S=zQ@mail.gmail.com>
	<547E0E63.2050101@blueyonder.co.uk>
	<547E3250.3000803@redhat.com>
	<1026298715.23276845.1417557590117.JavaMail.zimbra@redhat.com>
	<547EDF40.4050302@redhat.com>
	<CANVjZ_TffqC5ZC8g=ccs8eop=-D91b1bnymPvc9i+0e3YEt1PA@mail.gmail.com>
	<547EF24D.50701@redhat.com>
	<CACsaS953UedZYM3NvcWpFG+Fop-s8Py=eRW3KsGktWmPae5Pgw@mail.gmail.com>
	<CAFitrpTH92yDSbwH5bDNwiLDHJSxkUH=JoekM0ioPzQeHdEUiQ@mail.gmail.com>
	<CAFEMS4tk5UuOsKePqDKosM2YB3+-qt8GWV0cMi8FpMNzWX9btA@mail.gmail.com>
	<CANVjZ_R78aNOdZ-xb8QBx0bHGxK=q79nUkJimbDre4kYBTFUDw@mail.gmail.com>
	<CAFEMS4uh_c0ro=VALtybdZ1T-AiG7CK_CWU1wPpE7wxeRy2P_g@mail.gmail.com>
Date: Tue, 27 Jan 2015 11:46:07 +0100
Message-ID: 
 <CACsaS94DgE=W-hp9jo83560cSXZnPgg3keogVjLvg=vS_DkO5Q@mail.gmail.com>
Subject: Re: Any ETA on a QPid 0.32 release
From: Rob Godfrey <rob.j.godfrey@gmail.com>
To: "users@qpid.apache.org" <users@qpid.apache.org>,
 Keith W <keith.wall@gmail.com>
Cc: Justin Ross <justin.ross@gmail.com>
Content-Type: multipart/alternative; boundary=089e01294d506068f9050d9ff68b

--089e01294d506068f9050d9ff68b
Content-Type: text/plain; charset=UTF-8

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

--089e01294d506068f9050d9ff68b--