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 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. 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. 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.
