trafficserver-users mailing list archives

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

> On Aug 12, 2013, at 12:22 PM, Leif Hedstrom <> wrote:
> 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.

Wow, that's a humongous pain in the ass to deal with. I've done this before (Mozilla) and
it truly sucks big time to have to deal with this :-/.

Particularly dealing with live upgrading of the cache would be a monumental task, and *incredibly*

I can right now say I'm hugely -1 on this idea. To put it bluntly, I think we'd kill ourselves
and the project if we tried. ;)

>> Or are you proposing that we from now on, never make anything incompatible? Incompatible
>> 	* 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.

But I'm missing something then. If there's a support window, you are allowing incompatible
changes?  What does the support window define? "If you are running a version older then <n>
months, we'll not support you upgrading to this version" ?

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

These upgrade tools runs as part of starting traffic_server every time you start it ? Meaning,
I deploy my old configs, and a new binary, and suddenly the configs in the /etc/  directory
are modified for me? That seems like a non-starter already, considering that deployment state
is not the same as runtime state.

If you mean providing tools that upgrades my configs, I make new config packages, and push
that in conjunction with a binary update, then that's not compatible, right ? Compatible here
would imply I can replace the binaries only, and things will just magically work.

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

I agree 100% that having backward compatibility can be nice. I think it opens up an enormous
can of worm, that will make our project impossible to work with (but, that's just my biased,
unscientific opinion, please prove me wrong). This is why the proposal had the additional
release cycle for incompatible changes, with a longer release train (say, 1 / year).

I think the fixed dates is a very minor issue in comparison to the compatibility ideas. I
personally think it's a step in the wrong direction (the rest of the OpenSource world is moving
towards agile methodologies), but I would not oppose fixed release dates if that's the consensus
of the community. It certainly does make the release process predictable.


-- leif

View raw message