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? What if there's been no changes worthy of a release, do we
still make one?
Also, how do we deal with incompatibility changes? 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.
* 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.
* New configuration file format(s). [This might be possible to make
compatible, by preserving all old config formats as well as the new ones].
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 ?
Cheers,
-- Leif
