Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bloodhound-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of gstein@gmail.com designates
 209.85.214.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAKE9Bs9qnxGf0MBPCPjNwUXM9HQDh+9OXb0C7eu7fbH8=_ywEQ@mail.gmail.com>
References: <DA5DCB9B-4B0A-4CD2-91D9-DDFEE22D1751@wandisco.com>
	<CABD8fLV2SQWd6QgpcXTVKrTvx4Z_npGBbcHDxfsb6ycg0XBqWQ@mail.gmail.com>
	<CAKE9Bs9qnxGf0MBPCPjNwUXM9HQDh+9OXb0C7eu7fbH8=_ywEQ@mail.gmail.com>
Date: Wed, 10 Oct 2012 17:54:07 -0400
Message-ID: 
 <CABD8fLWeMaozrTxFmqU0fn81LdP2DquWM4szdoVcvpMGbi0yLA@mail.gmail.com>
Subject: Re: [Proposal] New release process
From: Greg Stein <gstein@gmail.com>
To: bloodhound-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=e89a8fb20566814d9f04cbbb7ebc

--e89a8fb20566814d9f04cbbb7ebc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=C5=BEelj" <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 glove=
s.
> > Beat it up. If the release is total crap, then turn the crank and relea=
se
> > 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 ye=
t
> > 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 (onc=
e
> > > 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 durin=
g
> > 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 nex=
t
> > > release. When the release is being packaged up, all tickets fixed sin=
ce
> > 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'r=
e
> > > 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 itse=
lf
> > is
> > > sound, not the possible exceptions.
> > >
> > > Cheers,
> > > Joe
> >
>

--e89a8fb20566814d9f04cbbb7ebc--