You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avro.apache.org by Ryan Skraba <ry...@skraba.com> on 2023/07/17 19:58:19 UTC
[DISCUSS] Release maintenance and lifecycle
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
Posted by 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
Posted by 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>
Re: [DISCUSS] Release maintenance and lifecycle
Posted by 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
Posted by Martin Grigorov <mg...@apache.org>.
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
Posted by Oscar Westra van Holthe - Kind <os...@westravanholthe.nl>.
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?
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).
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
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
On Tue, Aug 1, 2023 at 9:13 PM Ryan Skraba <ry...@skraba.com> wrote:
> 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)?
>
I believe that most of the time the branches will be similar to each other
and cherry-picking should be easy!
Hopefully this will also make us think twice before introducing a breaking
change!
> 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
Posted by 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 <ch...@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
Posted by Ryan Skraba <ry...@skraba.com>.
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 <ch...@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
Posted by Martin Grigorov <mg...@apache.org>.
I like Christophe's proposal !
On Tue, Jul 18, 2023 at 11:52 AM Christophe Le Saëc <ch...@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
Posted by Christophe Le Saëc <ch...@gmail.com>.
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
>