Do we need to make a decision on this particular point? Could we gauge community demand (people tend to ask for fixes to be backported in JIRA) and decide then?
If we make a good job of avoiding regressions, then it seems that each branch should really only need one or or a maximum of two bug fix releases. After that, users are welcome to upgrade to a new feature release (and hopefully to the most current) to get non-critical fixes and features. An exception is if we get security fixes. We probably do need a policy for how far we backport those. Ismael On Thu, Aug 11, 2016 at 4:35 AM, Gwen Shapira <g...@confluent.io> wrote: > Yeah, I agree that maintaining 6 release branches is not really > sustainable... > > Maybe 3 (current and 2 older) makes sense? > > On Wed, Aug 10, 2016 at 7:35 PM, 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. > > > > -- > Gwen Shapira > Product Manager | Confluent > 650.450.2760 | @gwenshap > Follow us: Twitter | blog >
