trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Peach <>
Subject Re: [PROPOSAL] New release process
Date Mon, 12 Aug 2013 19:32:52 GMT
On Aug 12, 2013, at 12:22 PM, Leif Hedstrom <> wrote:

> On Aug 12, 2013, at 1:02 PM, James Peach <> wrote:
>> On Aug 10, 2013, at 4:13 PM, Leif Hedstrom <> 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
> 	* 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.


View raw message