On Aug 12, 2013, at 2:33 PM, Reindl Harald <h.rei...@thelounge.net> wrote:
> > > Am 12.08.2013 22:28, schrieb James Peach: >> 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. > > +100 > > postfix is a perfect example for such a software > > if the packager was not a fool you can upgrade postfix > 2.4 to 2.10 without except breakage in most setups and > the few incompatible changes a mostly caught with safety-nets > and/or clearly documented We have never (afaik) made a stable release that breaks compatibility within that major release. v3.2.5 is 100% compatible to v3.2.0. For the few cases where we did break compatibility (twice so far, not counting the upgrade through our Incubation), they have been documented *). What you are describing with postfix seems pretty much identical to what we have today already. If I understand James' proposal, there would be no incompatible changes allowed in ATS, unless they also provide a completely automatic upgrade path. That's a pretty fundamental change in how we develop our software, and one that's incredibly difficult to accomplish in my experience. The idea of keeping master "always releasable is admirable (I like it!) but I think we'd have to change from CTR to RTC (Review Then Commit). Such a change is basically a bylaw change, and would have to be voted on separately. Considering Igor is the only one that regularly reviews commits, I think this would be a real hurdle and put progress in the community at risk. Ciao, -- leif *) https://cwiki.apache.org/confluence/display/TS/Upgrading+to+v3.2 https://cwiki.apache.org/confluence/display/TS/Upgrading+to+v3.4
