Back to this topic :D After a couple of extra releases on the branch-1.11, how do we feel about supporting two major releases? Have committers found it a pain in the butt to cherry-pick?
Imagine if we were to release 1.12.0 tomorrow... * master would be new features destined for 1.13.x * we would have branch-1.12 for the next minor release (as usual), but also * and branch-1.11 only for "patch" type releases (security fixes, dependency updates) I think this is doable, but it'll take a bit of commitment from all committers! If we supported 2 major releases (1.12 and 1.11 in the example above), I'd be happy to see security fixes released more often on the *older* supported major release -- I ran across a security analysis page (which I can't find now...) that gave Avro Java a 2/10 rating because of the infrequent releases. At the same time, I would probably prepare my "release validation" process a bit better so I could run through it faster. I'm not sure how everyone does theirs, but it can take me quite a bit of time. Releasing SDKs separately is another issue and a different discussion then vote but we should always have it in mind. It looks like rust is in pretty good shape while "kind of" doing it's own version ... but I can see THAT getting complicated in the future! Is there anything we need to address before opening a vote on whether we should maintain two major releases? All my best, Ryan On Wed, Aug 2, 2023 at 1:59 PM Martin Grigorov <mgrigo...@apache.org> wrote: > > On Wed, Aug 2, 2023 at 10:14 AM Oscar Westra van Holthe - Kind < > os...@westravanholthe.nl> wrote: > > > Hi everyone, > > > > The proposal so task has much to offer that (at least in my opinion) is > > worth the extra effort of maintaining a third branch. > > > > I'm not certain if we should also add non-breaking changes to the last > > maintenance release. Does this mean we release each branch separately when > > ready, and not all at once? > > > > IMO there is no need to release all branches at once. > The bug fix branch(es) could/should be released more often. The branch with > the new functionalities could be released as now once per year or more. > > > > > > One question though: do we keep the releases bundled with all languages? Or > > do we also want to split that? (I'd like to keep them bundled). > > > > "bundled" is easier for the release manager (I guess) and also for > generating the documentation. > I am fine with both approaches. > > > > > > > > > Kind regards, > > Oscar > > > > -- > > Oscar Westra van Holthe - Kind <os...@westravanholthe.nl> > > > > Op di 1 aug. 2023 20:12 schreef Ryan Skraba <r...@skraba.com>: > > > > > Bringing this subject back while it's still a bit fresh :D > > > > > > For the moment we seem to agree... But does anybody have any > > > objections _against_ maintaining two major version (by keeping the > > > *three* branches ready to release)? > > > > > > Playing the devil's advocate: it would be a bit more work to merge a > > > PR, with our already limited resources! > > > > > > What do you think? > > > > > > > > > > > > > > > On Wed, Jul 19, 2023 at 12:09 PM Ryan Skraba <r...@skraba.com> wrote: > > > > > > > > I think we're all agreeing so far! Let's say we release 1.12.0 today, > > > > the state would be > > > > > > > > master: 1.13.0-SNAPSHOT > > > > branch-1.12: 1.12.1-SNAPSHOT > > > > branch-1.11: 1.11.3-SNAPSHOT > > > > > > > > We would attempt to keep all three of those in a releasable state, but > > > > the moment we release 1.13.0, branch-1.11 drops off the list. > > > > > > > > It would be great to drop some @Deprecated APIs as well in a structured > > > way. > > > > > > > > I'm attaching the "table of contents" that I've been keeping for > > > > previous discussions on this! I remember there being a concern that > > > > "guaranteed maintenance" for a major release should be by time (at > > > > least X years, as opposed to Y versions). In practice, this hasn't > > > > been a problem (with the cadence of <1 major release a year). I think > > > > stating our intention to ensure that a major release receives updates > > > > for at least 2 years is a pretty good idea to include -- if we can't > > > > meet that goal, there's probably a pretty good reason (like a > > > > hopelessly broken major release that should be abandoned). > > > > > > > > I'll give this a bit more time to think about and maybe we can call a > > > > vote, write a policy for the website and move to the next topic on the > > > > list :D > > > > > > > > All my best, Ryan > > > > > > > > > > > > [1]: https://issues.apache.org/jira/browse/AVRO-2687 "Semantic > > > versioning" > > > > [2]: https://lists.apache.org/thread/6ppm20v5602w9nqz0nk5qz7mxnnt2tsw > > > > "[DISCUSS] version numbers and where changes should land" > > > > [3]: https://lists.apache.org/thread/2rfnszd4dk36jxynpj382b1717gbyv1y > > > > "Release language modules separately" > > > > [4]: https://lists.apache.org/thread/rybf7vb514mtkr7swfld7b06g1kb2r3t > > > > "[DISCUSS] Releases, versioning and lifecycle" > > > > [5]: https://lists.apache.org/thread/wq2k9lrz6g79j83t2ojwpvsh4zor4qfg > > > > "[[DISCUSS] Release maintenance and lifecycle" > > > > > > > > > > > > On Tue, Jul 18, 2023 at 9:54 PM Martin Grigorov <mgrigo...@apache.org> > > > wrote: > > > > > > > > > > I like Christophe's proposal ! > > > > > > > > > > On Tue, Jul 18, 2023 at 11:52 AM Christophe Le Saëc < > > > chles...@gmail.com> > > > > > wrote: > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > >
