Hello I find this proposal relevant. to clarify :
> From 1.12.0 on, I'd like to propose maintaining *two* major versions > (i.e. 1.12.x and 1.11.x). That would allow us to deprecate and modify > APIs and give developers one whole major release to switch. this means to maintain 3 branches (1.13.0-SNAPSHOT (master), 1.12.x and 1.11.x) ? what about ? - master (1.13.0-SNAPSHOT) receive new feature + CVE + bug fixes + API breaking change (keeping old API with deprecated tag when possible) and remove old deprecated API (possibly not compatible with 1.12.x) - 1.12.x receive from master new feature + CVE + bug fixes (1.12.n+1 should stay compatible with 1.12.n, so, it won't receive breaking change). - 1.11.x receive from master only CVE + bug fixes. thus allow users to adopt new feature even on minor released, and adapt smoothly to breaking change on major release. (this imply to distinguish between *new feature* and *breaking changes* ?) Best regards, Christophe. Le lun. 17 juil. 2023 à 21:59, Ryan Skraba <r...@skraba.com> a écrit : > Hello! There's a number of outstanding questions and discussions > about releases, maintenance, lifecycle :D I thought it might be > productive to make a goal to work towards. > > Specifically, I couldn't point to a policy about this question being > asked on the user@ mailing list: when do we stop maintaining a > version? My experience over the last few years has been that we only > have one version under development at a time. > > One of the major brakes in doing this last release was deciding what > to do with each and every commit on the master branch -- having a > concrete policy and decision on this would definitely help committers > decide when, what and where to cherry-pick changes! > > From 1.12.0 on, I'd like to propose maintaining *two* major versions > (i.e. 1.12.x and 1.11.x). That would allow us to deprecate and modify > APIs and give developers one whole major release to switch. The > "older" major version would receive *only* bug and security fixes, the > "newest" major version gets those as well as non-API breaking > features. > > All work is committed to master, and the committer makes the decision > how far to cherry-pick, or (in the absence of time) keeps the JIRA > fixVersion up-to-date for someone to pick up the intention. > > That's just one suggestion that seems plausible to me! We can > probably do better without much additional effort (on the limited > resources we have). What do you think? > > All my best regards, Ryan > > On Mon, Jul 17, 2023 at 9:43 PM Ryan Skraba <r...@skraba.com> wrote: > > > > Hello! While Avro doesn't have an official "end-of-life" statement or > > policy, there is no active development on the 1.9 or 1.10 branch. > > > > Our current policy is to add major features to the next major release > > (1.12.0) while bug fixes, CVEs and minor features will be backported > > to the next minor release (1.11.3). > > > > I think we *should* have a policy in place, for projects that depend > > on Avro to have a better visiblity. I will bring this up on the > > dev@avro.apache.org mailing list -- please feel free to join the > > discussion! > > > > All my best, Ryan > > > > > > On Mon, Jul 17, 2023 at 11:19 AM Pranav Kumar (EXT) via user > > <u...@avro.apache.org> wrote: > > > > > > Hi, > > > > > > > > > > > > Could you please share End of life/End of support detail or any EoS > criteria that is followed for below: > > > > > > > > > > > > Apache Avro version-1.9.2 > > > > > > > > > > > > Regards, > > > > > > Pranav >
