bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <>
Subject Re: [Proposal] New release process
Date Mon, 08 Oct 2012 15:42:03 GMT
On 08.10.2012 17:21, Gary Martin wrote:
> I can agree with the monthly release as a good idea in principle but I
> don't think that the meaningful milestones idea is that useful.
> I still want to see a milestone used to decide on a reasonable amount
> of work to do towards a given release. Feature development would
> essentially be cross milestone in this model. The component system may
> work well enough for that at the moment. The scope of the work
> expected for a given release is not made any more predictable by using
> milestones as cross-release categorisation.
> Personally I am hoping for a little more discipline from those who
> like to add more and more tickets to the active milestone.

No one should be bound by what's in an issue tracker (even if it's used
as a project planning tool). A release happens when the PMC decides one
is ready. Formal process is important for the release rollout itself;
anything else are just guidelines.

-- Brane

> On 08/10/12 13:15, Joachim Dreimann wrote:
>> Hi everyone,
>> I'd like to propose a new release process for releases after 0.2
>> (once accepted).
>> Our current process (as I understand it):
>> - A milestone containing tickets we believe should be fixed for the
>> release is created.
>> - Someone volunteers as release manager at an arbitrary point and
>> packages up a release ready to be voted on.
>> - All uncompleted tickets in the milestone are moved to the next
>> upcoming milestone.
>> In my opinion this is a messy process in which releases are
>> unpredictable in scope and frequency.
>> Proposed new process:
>> 1. Monthly release cycle with the packages ready to be voted on
>> during the first full week of the month.
>> 2. Milestones are for meaningful goals we're working towards. For
>> example: Multi product, Responsive Layout, etc
>> 3. Versions are set up reflecting the priority Milestones for the
>> next release. When the release is being packaged up, all tickets
>> fixed since the last release are assigned to the Version.
>> Obviously that would make the release frequency very predictable. I
>> believe it also better reflects our actual working practice in the
>> project better and make it easier for new contributors to pick up
>> tickets. Meaningful Milestones allow us to track how we're
>> progressing towards goals such as Multi Product or a Responsive
>> Layout over several versions. Versions would clearly reflect what has
>> been covered in each release, and bugs can be raised against them.
>> Longer term, with more contributors, we may get to a point where
>> we're able to complete one or more whole milestones within each
>> release cycle.
>> I'm sure we will come across situations where we need to make
>> exceptions to this process, but please provide feedback on whether
>> the plan itself is sound, not the possible exceptions.
>> Cheers,
>> Joe

Certified & Supported Apache Subversion Downloads:

View raw message