qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: Any ETA on a QPid 0.32 release
Date Tue, 02 Dec 2014 19:09:23 GMT
It has always felt slightly odd to me that Qpid has never had a version 
1.0. I guess that in the back of my mind (and back in the day) I perhaps 
assumed that it would hit V1.0 with AMQP 1.0 support, but that didn't occur.

I guess one thing that might be worth considering is to hold fire on a 
change until a couple of significant AMQP 1.0 changes occur - I guess 
that the two things that spring to mind would be
1) qpidd making AMQP 0.10 support optional
2) availability/maturity of the new Proton based AMQP 1.0 JMS client

TBH I don't really know the timeline for these and it might be a bit 
moot if they are a long way off, but I've always felt that there was a 
fair bit of confusion around the status of AMQP 1.0 JMS support so being 
able to deprecate the current interim client feels a fairly significant 
step on the maturity of AMQP 1.0 support.

Or is there a Qpid birthday coming up? The project running X years is 
probably another reasonable point to trigger a 1.0 release.


TBH I don't think the current numbering system is massively broken, at 
the very least it's something that we and most users have got used to. I 
think my personal preference is to pick a sensible point to move to 1.0, 
but I'm not going to die in a ditch about any other suggestions.

Frase

On 02/12/14 18:25, Robbie Gemmell wrote:
> On 2 December 2014 at 16:14, Rob Godfrey <rob.j.godfrey@gmail.com> wrote:
>> Can we also move from version 0.32 to something more reflective of the
>> maturity of the product?
>>
> Seems reasonable.
>
>> I feel like we've held off so long that going to release "1.0" now would
>> seem strange, and also imply something significant had happened in that
>> release which it hasn't.
> Agreed.
>
>> Personally I'd go for something like 15.1  (not
>> necessarily to indicate that we'd go for year.month in the future... but
>> just as a arbitrary starting point).
> <Arbitrary>.0 or <Year>.0 would suit me too.
>
> I'd quite like at least some components to support point releases
> eventually instead of just timed released, so in some ways arbitrary
> numbers seem preferable such that we dont end up doing too many odd
> looking point releases or even skipping numbers for slow moving
> components hehe.
>
>> I'd also be in favour of separating
>> out the components a bit - from the Java side we'd probably then look to
>> branch later but spend less time on a branch before release.
>>
> Do you mean branch at different points but still potentially release
> at similar times, or release at independent times? The latter was what
> I meant.
>
> A question for me is, if we did support releasing at different times
> then things will likely end up with different version numbers anyway,
> so do they need to start at the same place if we change from our
> historic naming convention? Would it be clearer or more confusing if
> they differed initially, or started the same and then diverged?
>
> One thing that I have mentioned before is that if we were to look at
> branching at different times, I think the repo needs better organised
> along the structure of likely branching, otherwise it just becomes a
> pain and the branches end up with potentially confusing junk on them
> for other bits. <Insert timely mention of Git, then run :P>.
>
> Robbie
>
>
>> -- Rob
>>
>> On 2 December 2014 at 16:48, Robbie Gemmell <robbie.gemmell@gmail.com>
>> wrote:
>>
>>> The releases have usually been every 4 months or so, and the branch
>>> for the last release was made about 4 months ago, so I guess the plan
>>> should be to branch sometime soon. Typically releases that begin in
>>> Nov/Dec dont emerge until some point in January. Any plans on dates
>>> Justin?
>>>
>>> Of course, we have discussed the project being more modular, updated
>>> the release artifacts along those lines to be more component based,
>>> and voted on them seperately last time round, so potentially we could
>>> look to take a further step and release different bits at different
>>> times now. Thoughts anyone?
>>>
>>> Robbie
>>>
>>> On 1 December 2014 at 22:11, Timothy Bish <tabish121@gmail.com> wrote:
>>>> We've been working on improving the AMQP 1.0 support in ActiveMQ and I've
>>>> found that the trunk code for QPid JMS client contains some fixes that
>>> would
>>>> be nice to have in for testing the fixes that are in the pipeline for the
>>>> broker.  Was wondering if there is any idea on when the 0.32 release
>>> process
>>>> might start rolling?
>>>>
>>>> --
>>>> Tim Bish
>>>> Sr Software Engineer | RedHat Inc.
>>>> tim.bish@redhat.com | www.redhat.com
>>>> skype: tabish121 | twitter: @tabish121
>>>> blog: http://timbish.blogspot.com/
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
> ---------------------------------------------------------------------
> 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


Mime
View raw message