+1 that deprecation schedule seems reasonable and a good thing to move to. > On Mar 29, 2021, at 10:23 AM, Benjamin Lerer <ble...@apache.org> wrote: > > The proposal sounds good to me too. > >> Le lun. 29 mars 2021 à 16:48, Brandon Williams <dri...@gmail.com> a écrit : >> >>> On Mon, Mar 29, 2021 at 9:41 AM Joseph Lynch <joe.e.ly...@gmail.com> >>> wrote: >>> I like the idea of the 3-year support cycles, but I think since >>> 3.0/3.11/4.0 took so long to stabilize to a point folks could upgrade >>> to, we should reset the clock somewhat. >> >> I agree, the length of time to release 4.0 and the initialization of a >> new release cycle requires some special consideration for current >> releases. >> >>> 4.0: Fully supported until April 2023 and high severity bugs until >>> April 2024 (2 year full, 1 year bugfix) >>> 3.11: Fully supported until April 2022 and high severity bugs until >>> April 2023 (1 year full, 1 year bugfix). >>> 3.0: Supported for high severity correctness/performance bugs until >>> April 2022 (1 year bugfix) >>> 2.2+2.1: EOL immediately. >>> >>> Then going forward we could have this nice pattern when we cut the >>> yearly release: >>> Y(n-0): Support for 3 years from now (2 full, 1 bugfix) >>> Y(n-1): Fully supported for 1 more year and supported for high >>> severity correctness/perf bugs 1 year after that (1 full, 1 bugfix) >>> Y(n-2): Supported for high severity correctness/bugs for 1 more year (1 >> bugfix) >> >> This sounds excellent to me, +1. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >> For additional commands, e-mail: dev-h...@cassandra.apache.org >> >>
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
