On 2 December 2014 at 19:31, Rob Godfrey <rob.j.godf...@gmail.com> wrote: > On 2 December 2014 at 19:25, Robbie Gemmell <robbie.gemm...@gmail.com> > 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. >> >> > Agreed - this is something I want to support too... from where I sit that > will be easier when each component has more control over their release > timelines. > > >> > 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. >> > > The latter should be possible, the former might be socially convenient (and > also mean less overall need for interop testing between components, which > is not something we seem to have well automated). One of my problems with > the current release process is that we always tend to take a *long* time in > the branched state, and the branching seems to occur at a somewhat > arbitrary point. I'd rather be saying "OK, we as a collection group of > developers for <X component> now believe we are ready to go to beta"... > >> >> 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? >> > > Right now it seems to me that the only coupling between the Java and C++ > releases is temporal, not functional. If we use a non date based version > numbering system, the coupling of the Java and C++ releases seems somewhat > odd - we don't currently (nor have we really ever) planned across the whole > project to coordinate functional releases. Similarly there's never really > any "good" time to move up major version while the releases are coupled > (since we never do "major" stuff at the same time) which is why I think > we've never gone to v1.0 previously. > > >> >> 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>. >> > > Agreed on better structure - I think git is somewhat orthogonal... We need > to get the structure right whatever.
Almost completely orthogonal really, I only mentioned it because of the obvious need to reorganise bits if they were to be split between multiple git repos, but we would probably want to change the structure before such a switch anyway. > > -- Rob > > >> 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
