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
