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 <[email protected]> wrote: > > Hi, > > On Wed, Sep 29, 2021 at 12:11 PM Ryan Skraba <[email protected]> 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" > >
