I think regular, on schedule releases are key for an Apache project - without them we are seen as less credible than other OS projects in the messaging space.
We have historically really struggled to get our releases out on time/as planned and across the ?5 years we've been going we have made (I think) 9 releases including those from incubator. We need to get faster and not be holding up the greater number of fixes for the last couple in each release. Only if we get quicker can we more rapidly evolve the product Apache users actually get to use :-) We also should really discuss testing as a group - we currently have a non-defined release gateway for testing, which lets us down somewhat. Just my tuppence - based on reading non-Apache Qpid people's assessments of messaging products in the OS space. Cheers, Marnie On Tue, Apr 19, 2011 at 5:10 PM, Steve Huston <shus...@riverace.com> wrote: > Hi Rajith, > > > Since we are striving hard to get into a habit of doing > > quarterly releases, we will at some point need to make some > > *hard" decisions in order to stick to our timelines. > > Therefore I think it's important we discuss how we make some > > of those decisions. > > Good idea - thanks for bringing it up. > > > A good example is QPID-3214 & QPID-3216 which are fairly > > serious regressions but perhaps not blockers in the current > > scheme of things. If we do not have another release coming in > > 2 months, I would updated their status as "blockers" and > > insist that we fix them. But if we do that for this release > > our dates would slip by another 2 weeks or so. And that may > > end up causing us to miss our goal of doing 4 release this > > year. I think as a project it's far more important for us to > > hit that goal compared to these two issues missing the 0.10 release. > > (Devil's advocate...) why is it so important to do 4 releases per year? > Would it really hurt to bump 0.10 out and include these fixes? > > > On the hand these issues can cause problems for our users, > > therefore we should also look at possible ways of fixing them > > between two major releases. One way of doing this is to make > > an errata release between two major releases. Again the > > questions would be, > > > > 1. Do we have enough time and resources to do this kind of > > thing ? 2. Will the errata release eat into our next release > > cycle ? 3. What if the next release gets delayed ? is that > > fair from a users pov ? > > > > I'd like to hear some thoughts about this from the community. > > My personal preference is to do an errata release for > > QPID-3214 & QPID-3216 (and any other serious issues like > > that). What do you guys think ? > > I tend to view errata/hotfix as services that downstream support > providers handle. You can use up a lot of time and effort going down > that road. > > If QPID-3214 and 3216 are serious issues I would prefer to hold 0.10 for > the fixes. The word "deadlock" in the jira subject seems serious, but > I'm wondering how likely it is a user will hit it if it hasn't been > found before. > > -Steve > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > >
