incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Koželj <pe...@digiverse.si>
Subject Re: [Proposal] New release process
Date Tue, 09 Oct 2012 08:49:07 GMT
Actually I was not trying to propose Eclipse scheme for pre 1.0 releases.
I think what we have right now is good enough until then.

All we need is higher frequency, anything between 4 and 6 weeks sounds
reasonable.

Peter

On Tue, Oct 9, 2012 at 9:21 AM, Greg Stein <gstein@gmail.com> wrote:

> 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
> repeatably.
>
> 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
> them.
>
> Cheers,
> -g
> On Oct 8, 2012 5:16 AM, "Joachim Dreimann" <joachim.dreimann@wandisco.com>
> 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
>

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