Mailing-List: contact users-help@trafficserver.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@trafficserver.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Date: Mon, 12 Aug 2013 21:40:08 +0000 (UTC)
From: Igor =?utf-8?Q?Gali=C4=87?= <i.galic@brainsware.org>
To: dev@trafficserver.apache.org
Cc: users@trafficserver.apache.org
Message-ID: <952461986.14074.1376343608272.JavaMail.zimbra@brainsware.org>
In-Reply-To: 
 <CABF6JR0C-EwCMxXjLLk6vonptTuaFtXaAyROrMfX4afGEErueA@mail.gmail.com>
References: <DD11424D-D5B1-427D-B657-6A1B9A1E4024@apache.org>
 <CABF6JR0C-EwCMxXjLLk6vonptTuaFtXaAyROrMfX4afGEErueA@mail.gmail.com>
Subject: Re: [PROPOSAL] New release process
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Thread-Topic: New release process
Thread-Index: AEsErDrc5+PNYfhsTzD69gG9m3NCCw==


----- Original Message -----
> On Sat, Aug 10, 2013 at 5:13 PM, Leif Hedstrom <zwoop@apache.org> wrote:
>=20
> > Hi all,
> >
> > I started a wiki with some ideas on how to streamline and simplify the
> > release process:
> >
> >
> > https://cwiki.apache.org/confluence/display/TS/New+Release+Processes
> >
> >
> > I'd like to start the discussion on this, and come to a consensus befor=
e
> > next stable release. One key decision here is what the next stable rele=
ase
> > should be versioned (I'm suggesting we make it v4.0, with no micro
> > version). The alternative is to keep it as we had planned, which would =
be
> > v3.4.0.
> >
> > Please discuss, and lets make the updates to that doc as appropriate.
> > Also, if the consensus is to leave the release process as is, we should
> > make that decision as well in the next 2 weeks.
> >
> > Cheers,
> >
> > -- leif
> >
> >
> >
> I think this is going in the wrong direction, personally. I don't like ho=
w
> we currently merge master into a dev branch to make a dev release. I feel
> like master and dev should be synonymous.

I never quite understood why Leif felt the need to create a (temporary)
-dev release branch. (but then I'm only starting to comprehend git)

> I don't think we've gotten enough testing on dev releases in the past, bu=
t
> I think that is changing now. I think we are close to achieving critical
> mass as far as participation goes. And I think that would only improve if
> dev and master were closer.
>=20
> As far as backporting goes, I think we should keep that to a minimum. We
> shouldn't be putting in new features. Only major bugs and security fixes.
> If people are longing for new features that are in the current stable
> release then we should be doing stable releases more often.

That's the way I've been handling it so far, and whoever follows me
as RM I hope does the same.=20
=20
> And as far as stable releases go I think we should do a little more
> planning. Much like we were able to do at the summit in Denver. Lets plan
> out what new features we think we can reasonably get into a release with =
a
> targetted time frame, but not let time dictate our releases. We should ha=
ve
> a roadmap available for our users. Lets just agree to have annual or
> bi-annual summits to hash this stuff out.
>=20
> Within those parameters I think it would be easiest to not have dev
> branches at all, and just put dev release tags on master. Then when we fe=
el
> we have met our feature requirements for a release (and feel free to add =
or
> subtract as things move along during the cycle) then we branch a stable
> branch and then do stabilzation on that branch until we feel it's ready f=
or
> the first stable release. New development can happen concurrently on
> master, but ideally we'd focus on stabilizing the release branch for the
> upcoming stable release.
>=20
> I think 4 releases a year is too much from a testing/deployment perspecti=
ve
> for software of this nature. 1 a year is maybe too little from a
> features/progress standpoint. Doing a minor (3.4 to 3.6) bump 2 or 3 time=
s
> a year seems reasonable to me. Probably closer to 2.

really? even two seems too much to me, but maybe growing up with httpd
I'm thinking too conservatively.

> When we want to break some major compatibility like on disk format of the
> cache (assuming we haven't gotten to some plugable model that negates thi=
s)
> we would bump the major version, ie 3.x to 4.x. Definitely not more than
> once a year, but probably more like once every 2+ years. I think we just
> need to roadmap out those changes appropriately.
>=20
> Sorry, this is a bit of a stream of consciousness but I was trying to
> adjust my response as this thread grew.
>=20

i

--=20
Igor Gali=C4=87

Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 6880 4155 74BD FD7C B515  2EA5 4B1D 9E08 A097 C9AE