On Aug 12, 2013, at 1:32 PM, James Peach <jpe...@apache.org> wrote: > On Aug 12, 2013, at 12:22 PM, Leif Hedstrom <zw...@apache.org> 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* risky. 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 he >> * 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. Cheers, -- leif
