You are viewing a plain text version of this content. The canonical link for it is here.

Posted to github@arrow.apache.org by GitBox <gi...@apache.org> on 2022/01/01 12:52:40 UTC

[GitHub] [arrow-rs] alamb opened a new issue #1120: More frequent major releases for arrow-rs

alamb opened a new issue #1120:
URL: https://github.com/apache/arrow-rs/issues/1120

TDLR: I propose doing major releases for arrow-rs more frequently (up to every other week) directly from `master`, breaking the correspondence with the main arrow release

For example, the release cadence might look like
* 2022-01-01: `7.0.0`
* 2022-01-15: `7.1.0` (no backwards incompatible changes)
* 2022-02-01: `8.0.0` (new backwards incompatible change)
* 2022-02-15: `9.0.0` (new backwards incompatible change)
* 2022-03-01: `9.1.0` etc
* 2022-03-15: `9.2.0`
* 2022-04-01: `9.3.0`
* 2022-04-15: `10.0.0`
...

**Is your feature request related to a problem or challenge? Please describe what you are trying to do.**

The rust ecosystem as a whole is "fast changing". This means:
1. Many pieces of the ecosystem change frequently that require downstream updates (e.g. new clippy lints released in stable versions of rust that require code fixes to pass CI)
2. Many crate authors don't spend effort maintaining stable releases, but instead fix issues by pushing new releases

This means the ability to quickly upgrade to new downstream libraries is critical to help fix issues like https://github.com/apache/arrow-rs/issues/1101

With a few notable exceptions (e.g. tokio) most of the rust ecosystem pushes new major releases frequently (monthly if not more so), often via `0.X` releases.

The current [release cadence and versioning scheme](https://github.com/apache/arrow-rs/blob/master/dev/release/README.md) of `arrow-rs` inherits from the C/C++ and python ecosystems with a major release every 3 months while maintaining a backwards compatible branch.

I propose moving the rust implementation in closer alignment with the rest of the rust ecosystem with more frequent major version releases.

**Describe the solution you'd like**

Continue to release every 2 weeks; However, release all new versions directly from the `master` branch, picking a new version number based on the changes in the crate (a new major version if there were semver changes, minor if not)

Pros:
1. Same number of releases as today (1 every other week)
2. Less branch maintenance overhead (selfishly good for me)
3. Major changes to dependencies(e.g. upgrade to newer versions of prost) available sooner

Cons:
1. downstream crates would likely have to do major updates more frequently (`cargo update` doesn't pick up new major versions)
2. Rust versions would no longer necessarily align with C++/etc mono repo release version

Much of the rust ecosystem, as described above, is used to the "do major updates frequently" mindset, and furthermore tools such as `dependabot` reduce the effort required to do so, I believe the first con is manageable.

**Describe alternatives you've considered**

Option: 1 "major release on demand", where we released when there were "enough" changes built up to do a regular release;

Option 2: keep the same structure (a `master` and `active_release` branch); do a major release every month instead of every 3 months, and do a minor release every other week.

--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org