On Mon, Aug 12, 2013 at 3:40 PM, Igor Galić <i.ga...@brainsware.org> wrote:
> > > ----- Original Message ----- > > On Sat, Aug 10, 2013 at 5:13 PM, Leif Hedstrom <zw...@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. > > I think we'd need to find the sweet spot. I think waiting too long people start complaining about not having feature X available in a stable release yet. Maybe we need to start with 2-3 a year then in a couple years settle out at 1 a year. I think right now there's so much to be done that we could sustain 2/year without a problem. In fact if there was some hybrid proposal that started off faster and looser and came into something stricter I might be able to get behind that. I just don't feel like I can +1 something that I don't see working long term. > > 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.ga...@brainsware.org > URL: http://brainsware.org/ > GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE > >
