Good question, let me clarify my thinking: We were used to doing every year (or even at lower frequency). So the expectation was that users will just upgrade once a year and we wouldn't worry about backporting bugfixes to bugs that were over a year old. It seemed pretty reasonable.
But if we are trying for 3 releases a year... well, almost no one (except Todd Palino) upgrades 3 times a year. Its like running 50 miles: Doable for some, but definitely not for everyone :) Basically, the same reasoning behind the desire to support upgrades for two years: We think it isn't reasonable to ask people to upgrade every 4 month, so we need to make sure that staying on a year-old version is still feasible and this includes fixing critical bugs that are found in the older release (that really isn't all that old) and publishing bugfix releases every once in a while. This doesn't really change the way we do versioning or branching (although our versioning could be slightly broken too, its a different story). It just means that I propose backporting more patches for critical bugs and doing some releases off older branches (which we didn't in the past). Does that make sense? Gwen 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? -- Gwen Shapira Product Manager | Confluent 650.450.2760 | @gwenshap Follow us: Twitter | blog
