Skipping release 1.2.1?

[parshimers]

Hi folks,
Given that there is an inevitable storage change (due to MinIO), and due to the number of issues with the release processes in general, I would like to start a discussion about whether or not 1.2.1 is a release that should be skipped. I think we haven't formalized the release cadence. I think there is one that was stated by some PPMC members, but I haven't seen a document describing the process. If someone with more knowledge of what the informal conventions are about the process could describe them here or in another thread, that would be great.

I think that we should focus all our energy on 1.3.0 . As stated, 1.2.1. isn't really a bugfix-only release, it can't be for a number of reasons. Backporting changes to 1.2.1 from main in addition to 1.3.0 is more work that we could be spending on getting 1.3.0 out the door. Furthermore auditing these 2 releases will take the same amount of work.

Thoughts?

[zyratlo]

I agree with putting the effort into 1.3.0. Looking at release/v1.2 and release/v1.3 right now, a lot of the recent commits are the same fixes landing on both branches, so the duplicate work is already happening.

If we're dropping 1.2.1, what should the status of 1.2.0 be? To my understanding, since the MinIO images can't be pulled anymore, a new 1.2.0 deployment doesn't work. If we skip 1.2.1, 1.3.0 becomes the first release that deploys without workarounds, so it's probably worth a short note on the download page pointing 1.2.0 users to 1.3.0.

[xuang7]

Thanks for starting this discussion. I agree that 1.3.0 should be the priority, and I'm not proposing to split effort between the two. I'd still like to keep 1.2.1 as a low-cost fallback for a few reasons.

One concern is that new deployments of 1.2.0 are affected by the removal of the MinIO images, which 1.2.1 aims to address. Its scope is relatively small: since 1.2.0, release/v1.2 has 50 commits touching 120 files, mostly covering the switch to RustFS and licensing fixes that 1.3.0 also needs. In comparison, release/v1.3 has 1,189 commits touching 2,047 files, including new services and modules (such as Jupyter and notebook migration), so its first RC and audit may take longer and could surface additional issues.

The extra work for 1.2.1 should be relatively limited, assuming no further major fixes are needed. Fixes land on main and are backported to both branches, so the remaining work on the 1.2 side would likely involve resolving a few backport conflicts and preparing another RC.

My suggestion is to focus on 1.3.0 for now and revisit the decision based on its progress. If 1.3.0 is ready for a vote within the next few weeks, we could skip 1.2.1 and add a note on the download page directing 1.2.0 users to 1.3.0, as @zyratlo suggested. If 1.3.0 takes longer than expected, we could consider proceeding with 1.2.1 RC2 to provide a working release in the meantime.

As the 1.2 release manager, I'm happy to follow the community's consensus on how best to proceed.

[Yicong-Huang]

I also still suggest we keep doing for both. For a few reasons:

1. v1.2.1 and v1.3.0 are quite different, as @xuang7 mentioned, v1.3 branch has 1000+ commits with new features. The existing users of v1.2.0's ability to upgrade to future 1.3.0 is unknown, and that may have possible delays caused by the new features (to fix them). Even if v1.3.0 can be ready for vote soon, it does not mean it will be easier to deploy and migrate, compared to v1.2.1.
2. The effort to fix v1.2 branch is not too much IMO. The same PRs are targeting to both release branches, and some fixes if needed on v1.2 should be a direct change without too much conflicts. I hope I am not underestimating @xuang7 's work on v1.2 after 1.2.0 release.

For the release cadency, that was discussed and voted on dev list. We should put this on the website if that's the concern.

One thing that is not clear from the current release cadency is the support length of a release line. We could start a discussion on that.
However, until v1.3.0 is released, v1.2.0 is our latest release, and I think we have a responsibility to fix issues in that release line and publish v1.2.1 as soon as possible. Otherwise, we’re effectively abandoning users on v1.2.0 and forcing them to upgrade just to get bug fixes.

[chenlica]

I support we do both 1.3.0 and 1.2.1 for the reasons mentioned above.