incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: [Proposal] New release process
Date Tue, 09 Oct 2012 07:21:10 GMT
Too much process. Just make a release every N weeks. If something is done,
then it gets in. If not, then maybe it gets in the next release. Don't be
afraid to ship bugs because they will be fixed in two weeks in the next
release. This is not 1.0 -- there is no need to treat it with kid gloves.
Beat it up. If the release is total crap, then turn the crank and release
again a few days later.

Don't get so hung up on what is in/out. Just make releases. Continually and

The goal is activity, to build community.

There should be (IMO) goals about features at this point in time.

I disagree with the Eclipse numbering before 1.0. The project is not yet
managing feature releases. 0.2 then 0.3 ... Version numbers are cheap. Use

On Oct 8, 2012 5:16 AM, "Joachim Dreimann" <>

> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message