Re: [DISCUSS] Release maintenance and lifecycle

[Ryan Skraba <ry...@skraba.com>]

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 <mg...@apache.org> wrote:
>
> On Wed, Aug 2, 2023 at 10:14 AM Oscar Westra van Holthe - Kind <
> oscar@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 <ry...@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 <ry...@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 <mg...@apache.org>
> > > wrote:
> > > > >
> > > > > I like Christophe's proposal !
> > > > >
> > > > > On Tue, Jul 18, 2023 at 11:52 AM Christophe Le Saëc <
> > > chlesaec@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 <ry...@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 <ry...@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
> > > > > > > > <us...@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
> > > > > > >
> > > > > >
> > >
> >

Re: [DISCUSS] Release maintenance and lifecycle

[Ryan Skraba <ry...@skraba.com>]

I think we can really see some process improvements as well!  I've
been taking a look at github actions or bots that could perform
cherry-picks (if conflict-free, of course) or back-porting PRs, and
I've found a few interesting projects *close* to it, like
https://github.com/gorillio/github-action-cherry-pick

I don't think dependabot will help us much here (allowing multple
target branches):
https://github.com/dependabot/dependabot-core/issues/2511 but I have
to admit that I haven't investigated too thoroughly -- if we had a
simple solution for backporting, it could cover this use case pretty
nicely!

Ideally, something like commenting: "Hey backportbot : please backport
this to branch-1.11" and it would either create a PR or just do the
cherry-pick, and/or report on success/failure.

And yes, I also agree -- it just feels wrong these days to be pushing
directly to a branch in the apache/avro repo!

One more thing to consider: we currently only run github actions on `master`...

There's lots of improvements to be made, but I kind of have the
feeling we could end up with a *simpler* build and release in the end!

All my best, Ryan




On Sat, Sep 23, 2023 at 7:26 AM Oscar Westra van Holthe - Kind
<os...@westravanholthe.nl> wrote:
>
> On fr 22 sep. 2023 18:40, Ryan Skraba <ry...@skraba.com> wrote:
>
> > 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?
> >
>
> Not a pain, but my process is not as clean as merging PR's: currently I
> cherry-pick directly onto the 1.11 branch.
>
> If the vote on this passes, I'd also like a way of working for this. Maybe
> cherry-picking directly is ok, maybe we want a policy to cherry-pick on a
> new branch and create a PR (even if that is then merged without review, as
> the original changes were already reviewed).
>
>
> Is there anything we need to address before opening a vote on whether
> > we should maintain two major releases?
> >
>
> Is it possible to configure dependabot to work on both master and the last
> two release branches? If so, that part would become easier.
>
>
> Kind regards,
> Oscar
>
> --
> Oscar Westra van Holthe - Kind <os...@westravanholthe.nl>

Re: [DISCUSS] Release maintenance and lifecycle

[Oscar Westra van Holthe - Kind <os...@westravanholthe.nl>]

On fr 22 sep. 2023 18:40, Ryan Skraba <ry...@skraba.com> wrote:

> 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?
>

Not a pain, but my process is not as clean as merging PR's: currently I
cherry-pick directly onto the 1.11 branch.

If the vote on this passes, I'd also like a way of working for this. Maybe
cherry-picking directly is ok, maybe we want a policy to cherry-pick on a
new branch and create a PR (even if that is then merged without review, as
the original changes were already reviewed).


Is there anything we need to address before opening a vote on whether
> we should maintain two major releases?
>

Is it possible to configure dependabot to work on both master and the last
two release branches? If so, that part would become easier.


Kind regards,
Oscar

-- 
Oscar Westra van Holthe - Kind <os...@westravanholthe.nl>