On Aug 12, 2013, at 12:56 PM, Leif Hedstrom <zw...@apache.org> wrote:
> 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" ? Well, we can't support every release forever, so we could say the that after 1 year, deprecated APIs get removed. >>> * 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. I don't think that a fast release cycle can work without strong compatibility guarantee. Who wants to deal with upgrade issues 3 or 4 times a year? The only way everyone will feel comfortable upgrading is if it a no-brainer and always works. J
