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 <[email protected]> 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 < > [email protected]> 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 <[email protected]> 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 <[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" > > > > > > > > > > > > > > -- > > > > ✉️ Oscar Westra van Holthe - Kind <[email protected]> > >
