incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
Subject Re: [Proposal] New release process
Date Wed, 10 Oct 2012 21:54:07 GMT
My preference would be 2 to 4 :-)

In 2001, I was in a position to effectively dictate that speed for
Subversion. It was a huge win for the nascent community.

Cheers,
-g
On Oct 9, 2012 1:49 AM, "Peter Koželj" <peter@digiverse.si> wrote:

> 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