On Aug 12, 2013, at 12:22 PM, Leif Hedstrom <zw...@apache.org> wrote:
> On Aug 12, 2013, at 1:02 PM, James Peach <jpe...@apache.org> wrote: > >> On Aug 10, 2013, at 4:13 PM, Leif Hedstrom <zw...@apache.org> wrote: >> >>> >>> 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. >> >> I'm going to ramble a bit here .... >> >> The most successful release process I've been a part of was the IRIX release >> process. We released every 3 months like clockwork. Every release was >> guaranteed to be forwards and backwards compatible with the previous >> releases. That strong guarantee is what allows the rapid release cycle to >> work, because people have confidence that upgrading will not be an >> unpleasant experience. > > 4 releases / year seems very reasonable to me. I'm not sure we can (or > should) be on a clockwork cycle, it feels very anti-agile to me personally. > For example, what if we need to make a release tomorrow, but it's only been 4 > weeks since last release? If we need to fix a critical bug or security issue, we would have to do an additional release. > What if there's been no changes worthy of a release, do we still make one? Yes. The goal here is to make the release reliable and predictable so that upgrading is not a scary experience or a lot of work. > > Also, how do we deal with incompatibility changes? Configurations and data formats should be automatically upgraded. Everything would need to be release noted thoroughly. > Or are you proposing that we from now on, never make anything incompatible? > Incompatible here would be e.g. > > * Cache needs to be reinitialized due to changes in layout (this has > happened numerous times). It's a real problem for many deployments if the > cache has to be reinitialized. We definitely should not break cache compatibility lightly, if ever. > * An API needs to be deprecated (and removed) in order to fix / change > something significant. For example, the new cache key proposal comes to mind. Mark as deprecated, then remove once the support window has passed. > * New configuration file format(s). [This might be possible to make > compatible, by preserving all old config formats as well as the new ones]. Automatic upgrade tools. > I'm sure there are other possible examples, but as far as I know, every major > release has broken some backward compatibility so far? > > >> >> I'm generally in favour of having a single release train that we push >> regularly. Every three months seems like a reasonable time frame, given the >> amount of work involved in packaging, deployment and release management. The >> key to making this work is to prove that we can deliver a strong >> compatibility guarantee. In order to make a strong compatibility guarantee, >> we need to make sure that master is always in a releasable state, that we >> always provide correct configuration upgrade tools, never regress >> performance, etc. Do we currently have sufficient test and performance >> coverage to be comfortable that we can do that? > > To answer the last question: No, we need much better tools in this area. > Power users have to step up to the plate. > > If I understand you correctly, you are proposing we are always upgrade > compatible, and only have one release train (based on master)? The delta of > this to the Wiki proposal would be (correct me if I'm wrong): > > * Remove the incompatibility branch and release cycle. There's only > master and the release branch. > * Define hard release dates (say, 9/1/2013, 12/1/2013, 3/1/2013 etc.) > > Does that sum it up ? Pretty much. I think the only way a rapid release cycle can work is if there is confidence that upgrading never breaks. IMHO, this is a good thing to have independent of the release process, but it's not necessarily easy to achieve. I think that fixed release dates focus the mind and make the process more predictable. J
