Hi Joel, I think my suggestion was misunderstood. :) I suggested that we should support upgrades to the latest release for a reasonable period (and I used 2 years as an example). That doesn't mean supporting all of those branches for that period. It simply means that we maintain the code necessary to support upgrading in trunk along with relevant system tests. For example, we currently support direct upgrades from 0.8.x to the unreleased 0.10.1.x (although we only have tests from 0.8.2.x onwards, 0.8.0.x and 0.8.1.x are missing). That's 5 releases, so we sort of do it already. I just wanted to emphasise the importance of making it easier for people to catch up to current releases (which is a different point from supporting people who want to stay on older releases).
Ismael On Thu, Aug 11, 2016 at 3:35 AM, Joel Koshy <jjkosh...@gmail.com> wrote: > On Wed, Aug 10, 2016 at 5:44 PM, Joel Koshy <jjkosh...@gmail.com> wrote: > > > > > > > On Tue, Aug 9, 2016 at 4:49 PM, Gwen Shapira <g...@confluent.io> wrote: > > > >> > >> 4. Frequent releases mean we need to do bugfix releases for older > >> branches. Right now we only do bugfix releases to latest release. > >> > > > > I'm a bit unclear on how the above is a side-effect of time-based > > releases. IIUC this just changes how frequently we release off the > current > > release branch right? Or put another way, are you also proposing any > > fundamental change to our versioning/branching scheme? > > > > Actually nm - so what you're saying is we cut more frequently off trunk > which means having to maintaining multiple release branches. However, the > more frequently we release then it should be less difficult to upgrade from > one release to another which means it should be reasonable to expect that > we EOL release branches sooner than later. > > However, if we are expected to maintain release branches for up to two > years then that means potential bugfix releases for up to eight release > branches at any given time? i.e., it seems that a short inter-release > interval would require us to EOL release branches sooner than that to make > things manageable. >
