incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Dreimann <joachim.dreim...@wandisco.com>
Subject [Proposal] New release process
Date Mon, 08 Oct 2012 12:15:22 GMT
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
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message