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.godf...@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.gemm...@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 <tabish...@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.b...@redhat.com | www.redhat.com
skype: tabish121 | twitter: @tabish121
blog: http://timbish.blogspot.com/
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
