trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Galić <i.ga...@brainsware.org>
Subject Re: [PROPOSAL] New release process
Date Mon, 12 Aug 2013 21:40:08 GMT


----- Original Message -----
> On Sat, Aug 10, 2013 at 5:13 PM, Leif Hedstrom <zwoop@apache.org> wrote:
> 
> > 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 before
> > next stable release. One key decision here is what the next stable release
> > 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 how
> 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, but
> 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.
> 
> 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. 
 
> 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 have
> a roadmap available for our users. Lets just agree to have annual or
> bi-annual summits to hash this stuff out.
> 
> 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 feel
> 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 for
> 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.
> 
> I think 4 releases a year is too much from a testing/deployment perspective
> 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 times
> 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 this)
> 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.
> 
> Sorry, this is a bit of a stream of consciousness but I was trying to
> adjust my response as this thread grew.
> 

i

-- 
Igor Galić

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


Mime
View raw message