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 2021/09/29 09:11:06 UTC
[DISCUSS] Releases, versioning and lifecycle
Hello!
There's been some discussion on JIRA/Github about how we version and
release Avro. I wanted to keep this separate from the 1.11.0
proposal, and collect some resources from the discussions we've had in
the past [1][2][3].
Right now, there's a request to backport a performance regression to a
minor release 1.10.3[4]. We've set our sights on the next major
release 1.11.0. I don't think we have an official policy on how many
major releases we plan on supporting, but I don't think we've ever
released a minor version once a new major version is on the horizon.
Currently, it's a pretty large task to prepare a new major release,
and it's always been a bit of pain doing a minor release because we
haven't been rigorous in backporting bug fixes to maintenance, and it
isn't always very clear which fixes should and shouldn't be applied!
I'd like to collect some opinions about what we should be doing, and
what we can do in the near term to make this clear and easy for
maintainers and users. The immediate question for me: how many major
versions should we be supporting, and how can we better communicate
officially this to the community?
All my best, Ryan
[1]: https://issues.apache.org/jira/browse/AVRO-2687 "Semantic versioning"
[2]: https://lists.apache.org/thread.html/16b68748464a7ce7232f12bbbf781cbfd5de982785d5648b6c564cc9%40%3Cdev.avro.apache.org%3E
"[DISCUSS] version numbers and where changes should land"
[3]: https://lists.apache.org/thread.html/r9ec7d8801186d3242e6d535adb547ba5068f5a4e0202ec1bd5d8912a%40%3Cdev.avro.apache.org%3E
"Proposal: RFCs for Avro 2.x"
[4]: https://github.com/apache/avro/pull/1333 "Backport AVRO-3048"
Re: [DISCUSS] Releases, versioning and lifecycle
Posted by Ryan Skraba <ry...@skraba.com>.
I like the idea of automating where possible :D I have a little
script that helps out with the process on my machine, but it's still
very much *manual*.
My experience so far with "minor" releases, like 1.10.2 is that we
haven't always been very rigorous with cherry-picking so it's a lot of
work for the release manager to go through all of the commits and
decide which ones "deserve" to be cherry-picked one at a time.
Cherry-picking as we go (either by automated tool or by hand) would
really simplify the process, and allow us to release more frequently
with little extra effort.
It would probably also help if the head of the repository was the next
planned release instead of the next major release, but I'm not sure
how that would work quite yet. If master were at 1.11.1-SNAPSHOT
today, it would mean one less cherry-pick, but when would be the right
moment to bump it to 1.12.0-SNAPSHOT?
It might be worthwhile to "give it a try" for one major release before
making it into a policy...
How long do you think support for a version would last ideally? It
seems like it would be a lot of work to maintain the "old" joda-time
features, but Avro 1.9.2 was less than two years ago!
As well, thanks for your clarifying comment on
https://github.com/apache/avro/pull/1333#issuecomment-1011640589 --
the avro-util tools show that there is a real need to at least clearly
outline the expectations for users of the libraries!
All my best, Ryan
On Wed, Jan 12, 2022 at 8:22 PM r <ra...@gmail.com> wrote:
>
> the ideal support policy (in my opinion) is on time, and not "version
> distance".
> however, given the lack of resources to back that up, would better
> automation help in any way?
>
> some of these fixes that i've seen are fairly small, "isolated" diffs.
> maybe some commit time automation could opportunistically back-port them?
>
> fleshing out this idea, if fixes were made to adhere to a commit title
> pattern (say "[FIX] - <rest of commit headline>"), it might be possible to
> write some commit hook that would take these diffs from master and see if
> they can successfully apply to older branches. if so - an automated PR
> could be filed by the tooling. if not, maybe a ticket could be auto-created
> by the tooling to backport fix X to branches Y and Z.
>
> On Tue, Jan 11, 2022 at 11:36 AM Oscar Westra van Holthe - Kind <
> oscar@westravanholthe.nl> wrote:
>
> > Hi all,
> >
> > On the notion of separate versioning: +1
> > Reasoning:
> >
> > - the various components have varying 'liveliness'; having versions
> > reflect that is more honest towards our users
> > - separate versioning allows major upgrades to functionality to be
> > reflected in the version number
> >
> > It would however, be important to document which version of the
> > specification is supported by the various versions of the components.
> >
> > On support: I'd opt to support the last N=2 "major" releases (currently
> > 1.10 & 1.11).
> >
> >
> > Kind regards,
> > Oscar
> >
> >
> > On Tue, 11 Jan 2022 at 19:19, Ryan Skraba <ry...@skraba.com> wrote:
> >
> > > Hi Martin -- I dropped this ball in September :D In 2022, I'd love
> > > to see some of these issues (1) documented and communicated, or (2)
> > > voted on and changed!
> > >
> > > Semantic versioning: The first number in the Avro version is the
> > > "binary over-the-wire specification" for the bytes that Avro writes,
> > > and I think the consensus is that it will probably always be 1, or
> > > it's no longer Avro. The next two are major and minor versions "like"
> > > SemVer. I have only seen a four number version once (Avro python
> > > 1.9.2.1) which was to fix a publishing error on PyPI.
> > >
> > > I don't think we have official policies, but bug fixes and backwards
> > > compatible new features go into a new minor version (like 1.10.2) and
> > > breaking changes or big features in a new major version (1.11.0). We
> > > should never have serialization changes, although we've had some
> > > additions to the spec (like enum defaults).
> > >
> > > Separate SDK versioning: We currently release all versions together
> > > regardless of which SDKs have had breaking binary- or
> > > source-compatibility changes or bugfixes.
> > >
> > > Going through the history of the conversations, it seems like most
> > > contributors are in favor of moving to semantic versioning and doing
> > > bugfix releases for languages independently "one day", but it's a bit
> > > worrying to change the status quo because of the extra effort it might
> > > take!
> > >
> > > One thing I agree on is that it would be good for users if we support
> > > more than one major version: ideally with all CVE, regressions and bug
> > > fixes in the older one. Would anybody object voting on that
> > > independently of any other changes?
> > >
> > > Another great thing with the upcoming home page redesign is that we
> > > can have a place to record these types of decisions and link to the
> > > mailing list!
> > >
> > > All my best, Ryan
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Wed, Sep 29, 2021 at 3:08 PM Martin Grigorov <mg...@apache.org>
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > On Wed, Sep 29, 2021 at 12:11 PM Ryan Skraba <ry...@skraba.com> wrote:
> > > >
> > > > > Hello!
> > > > >
> > > > > There's been some discussion on JIRA/Github about how we version and
> > > > > release Avro. I wanted to keep this separate from the 1.11.0
> > > > > proposal, and collect some resources from the discussions we've had
> > in
> > > > > the past [1][2][3].
> > > > >
> > > > > Right now, there's a request to backport a performance regression to
> > a
> > > > > minor release 1.10.3[4]. We've set our sights on the next major
> > > > > release 1.11.0. I don't think we have an official policy on how many
> > > > > major releases we plan on supporting, but I don't think we've ever
> > > > > released a minor version once a new major version is on the horizon.
> > > > >
> > > > > Currently, it's a pretty large task to prepare a new major release,
> > > > >
> > > >
> > > > By "major" you mean 1.11.0, right ? I.e. we don't talk about SemVer
> > major
> > > > here, i.e. 2.0.0
> > > >
> > > >
> > > > > and it's always been a bit of pain doing a minor release because we
> > > > > haven't been rigorous in backporting bug fixes to maintenance, and it
> > > > > isn't always very clear which fixes should and shouldn't be applied!
> > > > >
> > > > > I'd like to collect some opinions about what we should be doing, and
> > > > > what we can do in the near term to make this clear and easy for
> > > > > maintainers and users. The immediate question for me: how many major
> > > > > versions should we be supporting, and how can we better communicate
> > > > > officially this to the community?
> > > > >
> > > >
> > > > Since there are not many active maintainers I'd say at most two
> > versions:
> > > > - the new major, e.g. 1.11.0
> > > > - a patch version for regressions, e.g. 1.10.3
> > > > This would mean that once 1.11.0 is released any users of 1.9.x and
> > older
> > > > won't get any updates.
> > > > The next release could be 1.11.1+1.10.4 or 1.12.0+1.11.1. Depends on
> > how
> > > > many regressions have been found in 1.11.0.
> > > >
> > > >
> > > > Which fixes to backport to the patch version ? I see these options:
> > > > 1) all bug fixes
> > > > 2) only the bug fixes requested by the reporter or other users
> > > >
> > > > Another question: When making a release for a patch version, like
> > 1.10.3,
> > > > you'd release all langs or just the ones having any backports ? I guess
> > > the
> > > > latter because it would reduce the work to cut a release
> > > >
> > > > Regards,
> > > > Martin
> > > >
> > > >
> > > > > All my best, Ryan
> > > > >
> > > > > [1]: https://issues.apache.org/jira/browse/AVRO-2687 "Semantic
> > > versioning"
> > > > > [2]:
> > > > >
> > >
> > https://lists.apache.org/thread.html/16b68748464a7ce7232f12bbbf781cbfd5de982785d5648b6c564cc9%40%3Cdev.avro.apache.org%3E
> > > > > "[DISCUSS] version numbers and where changes should land"
> > > > > [3]:
> > > > >
> > >
> > https://lists.apache.org/thread.html/r9ec7d8801186d3242e6d535adb547ba5068f5a4e0202ec1bd5d8912a%40%3Cdev.avro.apache.org%3E
> > > > > "Proposal: RFCs for Avro 2.x"
> > > > > [4]: https://github.com/apache/avro/pull/1333 "Backport AVRO-3048"
> > > > >
> > >
> >
> >
> > --
> >
> > ✉️ Oscar Westra van Holthe - Kind <os...@westravanholthe.nl>
> >
Re: [DISCUSS] Releases, versioning and lifecycle
Posted by r <ra...@gmail.com>.
the ideal support policy (in my opinion) is on time, and not "version
distance".
however, given the lack of resources to back that up, would better
automation help in any way?
some of these fixes that i've seen are fairly small, "isolated" diffs.
maybe some commit time automation could opportunistically back-port them?
fleshing out this idea, if fixes were made to adhere to a commit title
pattern (say "[FIX] - <rest of commit headline>"), it might be possible to
write some commit hook that would take these diffs from master and see if
they can successfully apply to older branches. if so - an automated PR
could be filed by the tooling. if not, maybe a ticket could be auto-created
by the tooling to backport fix X to branches Y and Z.
On Tue, Jan 11, 2022 at 11:36 AM Oscar Westra van Holthe - Kind <
oscar@westravanholthe.nl> wrote:
> Hi all,
>
> On the notion of separate versioning: +1
> Reasoning:
>
> - the various components have varying 'liveliness'; having versions
> reflect that is more honest towards our users
> - separate versioning allows major upgrades to functionality to be
> reflected in the version number
>
> It would however, be important to document which version of the
> specification is supported by the various versions of the components.
>
> On support: I'd opt to support the last N=2 "major" releases (currently
> 1.10 & 1.11).
>
>
> Kind regards,
> Oscar
>
>
> On Tue, 11 Jan 2022 at 19:19, Ryan Skraba <ry...@skraba.com> wrote:
>
> > Hi Martin -- I dropped this ball in September :D In 2022, I'd love
> > to see some of these issues (1) documented and communicated, or (2)
> > voted on and changed!
> >
> > Semantic versioning: The first number in the Avro version is the
> > "binary over-the-wire specification" for the bytes that Avro writes,
> > and I think the consensus is that it will probably always be 1, or
> > it's no longer Avro. The next two are major and minor versions "like"
> > SemVer. I have only seen a four number version once (Avro python
> > 1.9.2.1) which was to fix a publishing error on PyPI.
> >
> > I don't think we have official policies, but bug fixes and backwards
> > compatible new features go into a new minor version (like 1.10.2) and
> > breaking changes or big features in a new major version (1.11.0). We
> > should never have serialization changes, although we've had some
> > additions to the spec (like enum defaults).
> >
> > Separate SDK versioning: We currently release all versions together
> > regardless of which SDKs have had breaking binary- or
> > source-compatibility changes or bugfixes.
> >
> > Going through the history of the conversations, it seems like most
> > contributors are in favor of moving to semantic versioning and doing
> > bugfix releases for languages independently "one day", but it's a bit
> > worrying to change the status quo because of the extra effort it might
> > take!
> >
> > One thing I agree on is that it would be good for users if we support
> > more than one major version: ideally with all CVE, regressions and bug
> > fixes in the older one. Would anybody object voting on that
> > independently of any other changes?
> >
> > Another great thing with the upcoming home page redesign is that we
> > can have a place to record these types of decisions and link to the
> > mailing list!
> >
> > All my best, Ryan
> >
> >
> >
> >
> >
> >
> > On Wed, Sep 29, 2021 at 3:08 PM Martin Grigorov <mg...@apache.org>
> > wrote:
> > >
> > > Hi,
> > >
> > > On Wed, Sep 29, 2021 at 12:11 PM Ryan Skraba <ry...@skraba.com> wrote:
> > >
> > > > Hello!
> > > >
> > > > There's been some discussion on JIRA/Github about how we version and
> > > > release Avro. I wanted to keep this separate from the 1.11.0
> > > > proposal, and collect some resources from the discussions we've had
> in
> > > > the past [1][2][3].
> > > >
> > > > Right now, there's a request to backport a performance regression to
> a
> > > > minor release 1.10.3[4]. We've set our sights on the next major
> > > > release 1.11.0. I don't think we have an official policy on how many
> > > > major releases we plan on supporting, but I don't think we've ever
> > > > released a minor version once a new major version is on the horizon.
> > > >
> > > > Currently, it's a pretty large task to prepare a new major release,
> > > >
> > >
> > > By "major" you mean 1.11.0, right ? I.e. we don't talk about SemVer
> major
> > > here, i.e. 2.0.0
> > >
> > >
> > > > and it's always been a bit of pain doing a minor release because we
> > > > haven't been rigorous in backporting bug fixes to maintenance, and it
> > > > isn't always very clear which fixes should and shouldn't be applied!
> > > >
> > > > I'd like to collect some opinions about what we should be doing, and
> > > > what we can do in the near term to make this clear and easy for
> > > > maintainers and users. The immediate question for me: how many major
> > > > versions should we be supporting, and how can we better communicate
> > > > officially this to the community?
> > > >
> > >
> > > Since there are not many active maintainers I'd say at most two
> versions:
> > > - the new major, e.g. 1.11.0
> > > - a patch version for regressions, e.g. 1.10.3
> > > This would mean that once 1.11.0 is released any users of 1.9.x and
> older
> > > won't get any updates.
> > > The next release could be 1.11.1+1.10.4 or 1.12.0+1.11.1. Depends on
> how
> > > many regressions have been found in 1.11.0.
> > >
> > >
> > > Which fixes to backport to the patch version ? I see these options:
> > > 1) all bug fixes
> > > 2) only the bug fixes requested by the reporter or other users
> > >
> > > Another question: When making a release for a patch version, like
> 1.10.3,
> > > you'd release all langs or just the ones having any backports ? I guess
> > the
> > > latter because it would reduce the work to cut a release
> > >
> > > Regards,
> > > Martin
> > >
> > >
> > > > All my best, Ryan
> > > >
> > > > [1]: https://issues.apache.org/jira/browse/AVRO-2687 "Semantic
> > versioning"
> > > > [2]:
> > > >
> >
> https://lists.apache.org/thread.html/16b68748464a7ce7232f12bbbf781cbfd5de982785d5648b6c564cc9%40%3Cdev.avro.apache.org%3E
> > > > "[DISCUSS] version numbers and where changes should land"
> > > > [3]:
> > > >
> >
> https://lists.apache.org/thread.html/r9ec7d8801186d3242e6d535adb547ba5068f5a4e0202ec1bd5d8912a%40%3Cdev.avro.apache.org%3E
> > > > "Proposal: RFCs for Avro 2.x"
> > > > [4]: https://github.com/apache/avro/pull/1333 "Backport AVRO-3048"
> > > >
> >
>
>
> --
>
> ✉️ Oscar Westra van Holthe - Kind <os...@westravanholthe.nl>
>
Re: [DISCUSS] Releases, versioning and lifecycle
Posted by Oscar Westra van Holthe - Kind <os...@westravanholthe.nl>.
Hi all,
On the notion of separate versioning: +1
Reasoning:
- the various components have varying 'liveliness'; having versions
reflect that is more honest towards our users
- separate versioning allows major upgrades to functionality to be
reflected in the version number
It would however, be important to document which version of the
specification is supported by the various versions of the components.
On support: I'd opt to support the last N=2 "major" releases (currently
1.10 & 1.11).
Kind regards,
Oscar
On Tue, 11 Jan 2022 at 19:19, Ryan Skraba <ry...@skraba.com> wrote:
> Hi Martin -- I dropped this ball in September :D In 2022, I'd love
> to see some of these issues (1) documented and communicated, or (2)
> voted on and changed!
>
> Semantic versioning: The first number in the Avro version is the
> "binary over-the-wire specification" for the bytes that Avro writes,
> and I think the consensus is that it will probably always be 1, or
> it's no longer Avro. The next two are major and minor versions "like"
> SemVer. I have only seen a four number version once (Avro python
> 1.9.2.1) which was to fix a publishing error on PyPI.
>
> I don't think we have official policies, but bug fixes and backwards
> compatible new features go into a new minor version (like 1.10.2) and
> breaking changes or big features in a new major version (1.11.0). We
> should never have serialization changes, although we've had some
> additions to the spec (like enum defaults).
>
> Separate SDK versioning: We currently release all versions together
> regardless of which SDKs have had breaking binary- or
> source-compatibility changes or bugfixes.
>
> Going through the history of the conversations, it seems like most
> contributors are in favor of moving to semantic versioning and doing
> bugfix releases for languages independently "one day", but it's a bit
> worrying to change the status quo because of the extra effort it might
> take!
>
> One thing I agree on is that it would be good for users if we support
> more than one major version: ideally with all CVE, regressions and bug
> fixes in the older one. Would anybody object voting on that
> independently of any other changes?
>
> Another great thing with the upcoming home page redesign is that we
> can have a place to record these types of decisions and link to the
> mailing list!
>
> All my best, Ryan
>
>
>
>
>
>
> On Wed, Sep 29, 2021 at 3:08 PM Martin Grigorov <mg...@apache.org>
> wrote:
> >
> > Hi,
> >
> > On Wed, Sep 29, 2021 at 12:11 PM Ryan Skraba <ry...@skraba.com> wrote:
> >
> > > Hello!
> > >
> > > There's been some discussion on JIRA/Github about how we version and
> > > release Avro. I wanted to keep this separate from the 1.11.0
> > > proposal, and collect some resources from the discussions we've had in
> > > the past [1][2][3].
> > >
> > > Right now, there's a request to backport a performance regression to a
> > > minor release 1.10.3[4]. We've set our sights on the next major
> > > release 1.11.0. I don't think we have an official policy on how many
> > > major releases we plan on supporting, but I don't think we've ever
> > > released a minor version once a new major version is on the horizon.
> > >
> > > Currently, it's a pretty large task to prepare a new major release,
> > >
> >
> > By "major" you mean 1.11.0, right ? I.e. we don't talk about SemVer major
> > here, i.e. 2.0.0
> >
> >
> > > and it's always been a bit of pain doing a minor release because we
> > > haven't been rigorous in backporting bug fixes to maintenance, and it
> > > isn't always very clear which fixes should and shouldn't be applied!
> > >
> > > I'd like to collect some opinions about what we should be doing, and
> > > what we can do in the near term to make this clear and easy for
> > > maintainers and users. The immediate question for me: how many major
> > > versions should we be supporting, and how can we better communicate
> > > officially this to the community?
> > >
> >
> > Since there are not many active maintainers I'd say at most two versions:
> > - the new major, e.g. 1.11.0
> > - a patch version for regressions, e.g. 1.10.3
> > This would mean that once 1.11.0 is released any users of 1.9.x and older
> > won't get any updates.
> > The next release could be 1.11.1+1.10.4 or 1.12.0+1.11.1. Depends on how
> > many regressions have been found in 1.11.0.
> >
> >
> > Which fixes to backport to the patch version ? I see these options:
> > 1) all bug fixes
> > 2) only the bug fixes requested by the reporter or other users
> >
> > Another question: When making a release for a patch version, like 1.10.3,
> > you'd release all langs or just the ones having any backports ? I guess
> the
> > latter because it would reduce the work to cut a release
> >
> > Regards,
> > Martin
> >
> >
> > > All my best, Ryan
> > >
> > > [1]: https://issues.apache.org/jira/browse/AVRO-2687 "Semantic
> versioning"
> > > [2]:
> > >
> https://lists.apache.org/thread.html/16b68748464a7ce7232f12bbbf781cbfd5de982785d5648b6c564cc9%40%3Cdev.avro.apache.org%3E
> > > "[DISCUSS] version numbers and where changes should land"
> > > [3]:
> > >
> https://lists.apache.org/thread.html/r9ec7d8801186d3242e6d535adb547ba5068f5a4e0202ec1bd5d8912a%40%3Cdev.avro.apache.org%3E
> > > "Proposal: RFCs for Avro 2.x"
> > > [4]: https://github.com/apache/avro/pull/1333 "Backport AVRO-3048"
> > >
>
--
✉️ Oscar Westra van Holthe - Kind <os...@westravanholthe.nl>
Re: [DISCUSS] Releases, versioning and lifecycle
Posted by Ryan Skraba <ry...@skraba.com>.
Hi Martin -- I dropped this ball in September :D In 2022, I'd love
to see some of these issues (1) documented and communicated, or (2)
voted on and changed!
Semantic versioning: The first number in the Avro version is the
"binary over-the-wire specification" for the bytes that Avro writes,
and I think the consensus is that it will probably always be 1, or
it's no longer Avro. The next two are major and minor versions "like"
SemVer. I have only seen a four number version once (Avro python
1.9.2.1) which was to fix a publishing error on PyPI.
I don't think we have official policies, but bug fixes and backwards
compatible new features go into a new minor version (like 1.10.2) and
breaking changes or big features in a new major version (1.11.0). We
should never have serialization changes, although we've had some
additions to the spec (like enum defaults).
Separate SDK versioning: We currently release all versions together
regardless of which SDKs have had breaking binary- or
source-compatibility changes or bugfixes.
Going through the history of the conversations, it seems like most
contributors are in favor of moving to semantic versioning and doing
bugfix releases for languages independently "one day", but it's a bit
worrying to change the status quo because of the extra effort it might
take!
One thing I agree on is that it would be good for users if we support
more than one major version: ideally with all CVE, regressions and bug
fixes in the older one. Would anybody object voting on that
independently of any other changes?
Another great thing with the upcoming home page redesign is that we
can have a place to record these types of decisions and link to the
mailing list!
All my best, Ryan
On Wed, Sep 29, 2021 at 3:08 PM Martin Grigorov <mg...@apache.org> wrote:
>
> Hi,
>
> On Wed, Sep 29, 2021 at 12:11 PM Ryan Skraba <ry...@skraba.com> wrote:
>
> > Hello!
> >
> > There's been some discussion on JIRA/Github about how we version and
> > release Avro. I wanted to keep this separate from the 1.11.0
> > proposal, and collect some resources from the discussions we've had in
> > the past [1][2][3].
> >
> > Right now, there's a request to backport a performance regression to a
> > minor release 1.10.3[4]. We've set our sights on the next major
> > release 1.11.0. I don't think we have an official policy on how many
> > major releases we plan on supporting, but I don't think we've ever
> > released a minor version once a new major version is on the horizon.
> >
> > Currently, it's a pretty large task to prepare a new major release,
> >
>
> By "major" you mean 1.11.0, right ? I.e. we don't talk about SemVer major
> here, i.e. 2.0.0
>
>
> > and it's always been a bit of pain doing a minor release because we
> > haven't been rigorous in backporting bug fixes to maintenance, and it
> > isn't always very clear which fixes should and shouldn't be applied!
> >
> > I'd like to collect some opinions about what we should be doing, and
> > what we can do in the near term to make this clear and easy for
> > maintainers and users. The immediate question for me: how many major
> > versions should we be supporting, and how can we better communicate
> > officially this to the community?
> >
>
> Since there are not many active maintainers I'd say at most two versions:
> - the new major, e.g. 1.11.0
> - a patch version for regressions, e.g. 1.10.3
> This would mean that once 1.11.0 is released any users of 1.9.x and older
> won't get any updates.
> The next release could be 1.11.1+1.10.4 or 1.12.0+1.11.1. Depends on how
> many regressions have been found in 1.11.0.
>
>
> Which fixes to backport to the patch version ? I see these options:
> 1) all bug fixes
> 2) only the bug fixes requested by the reporter or other users
>
> Another question: When making a release for a patch version, like 1.10.3,
> you'd release all langs or just the ones having any backports ? I guess the
> latter because it would reduce the work to cut a release
>
> Regards,
> Martin
>
>
> > All my best, Ryan
> >
> > [1]: https://issues.apache.org/jira/browse/AVRO-2687 "Semantic versioning"
> > [2]:
> > https://lists.apache.org/thread.html/16b68748464a7ce7232f12bbbf781cbfd5de982785d5648b6c564cc9%40%3Cdev.avro.apache.org%3E
> > "[DISCUSS] version numbers and where changes should land"
> > [3]:
> > https://lists.apache.org/thread.html/r9ec7d8801186d3242e6d535adb547ba5068f5a4e0202ec1bd5d8912a%40%3Cdev.avro.apache.org%3E
> > "Proposal: RFCs for Avro 2.x"
> > [4]: https://github.com/apache/avro/pull/1333 "Backport AVRO-3048"
> >
Re: [DISCUSS] Releases, versioning and lifecycle
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
On Wed, Sep 29, 2021 at 12:11 PM Ryan Skraba <ry...@skraba.com> wrote:
> Hello!
>
> There's been some discussion on JIRA/Github about how we version and
> release Avro. I wanted to keep this separate from the 1.11.0
> proposal, and collect some resources from the discussions we've had in
> the past [1][2][3].
>
> Right now, there's a request to backport a performance regression to a
> minor release 1.10.3[4]. We've set our sights on the next major
> release 1.11.0. I don't think we have an official policy on how many
> major releases we plan on supporting, but I don't think we've ever
> released a minor version once a new major version is on the horizon.
>
> Currently, it's a pretty large task to prepare a new major release,
>
By "major" you mean 1.11.0, right ? I.e. we don't talk about SemVer major
here, i.e. 2.0.0
> and it's always been a bit of pain doing a minor release because we
> haven't been rigorous in backporting bug fixes to maintenance, and it
> isn't always very clear which fixes should and shouldn't be applied!
>
> I'd like to collect some opinions about what we should be doing, and
> what we can do in the near term to make this clear and easy for
> maintainers and users. The immediate question for me: how many major
> versions should we be supporting, and how can we better communicate
> officially this to the community?
>
Since there are not many active maintainers I'd say at most two versions:
- the new major, e.g. 1.11.0
- a patch version for regressions, e.g. 1.10.3
This would mean that once 1.11.0 is released any users of 1.9.x and older
won't get any updates.
The next release could be 1.11.1+1.10.4 or 1.12.0+1.11.1. Depends on how
many regressions have been found in 1.11.0.
Which fixes to backport to the patch version ? I see these options:
1) all bug fixes
2) only the bug fixes requested by the reporter or other users
Another question: When making a release for a patch version, like 1.10.3,
you'd release all langs or just the ones having any backports ? I guess the
latter because it would reduce the work to cut a release
Regards,
Martin
> All my best, Ryan
>
> [1]: https://issues.apache.org/jira/browse/AVRO-2687 "Semantic versioning"
> [2]:
> https://lists.apache.org/thread.html/16b68748464a7ce7232f12bbbf781cbfd5de982785d5648b6c564cc9%40%3Cdev.avro.apache.org%3E
> "[DISCUSS] version numbers and where changes should land"
> [3]:
> https://lists.apache.org/thread.html/r9ec7d8801186d3242e6d535adb547ba5068f5a4e0202ec1bd5d8912a%40%3Cdev.avro.apache.org%3E
> "Proposal: RFCs for Avro 2.x"
> [4]: https://github.com/apache/avro/pull/1333 "Backport AVRO-3048"
>