Request to adjust the release plan

[FeynmanZhou]

Hi ORAS maintainers @oras-project/oras-cli ,

To make the ORAS release plan more user-friendly, I would like to request to adjust the ORAS CLI release plans as follows after revisiting the existing ORAS releases and clarifying the release management process in the governance guideline.

Cut a patch release for ORAS CLI v1.0.0

ORAS CLI v1.0.0 was released on Mar 20. As this is the first stable release, we may need to consider providing relatively "long-term" support for this release until v1.3.0 or v2 is out. I also add more clarity to the release support strategy in the ORAS release management guideline, see this PR.

ORAS CLI v1.1.0-RC.1 was released on July 13 and the release-1.1 branch is in active maintenance over the past four months. Introducing necessary bug fixes from release-1.1 branch to the release-1.0 branch then cut a patch release (v1.0.1) could be an appropriate option to maintain ORAS v1.

I would recommend ORAS CLI maintainers @oras-project/oras-cli merge all commits from release-1.1 branch to release-1.0 branch except for this new feature. The detailed commit comparison is listed here. Afterward, we can cut a patch release ORAS v1.0.1 from the release-1.0 branch.

Plan a new milestone ORAS CLI v1.1.0-RC.2 to support OCI Image-spec v1.1.0-rc.4

ORAS CLI v1.1.0-rc.1 as a Minor release but there is only one new feature as a small optimization introduced in this release. It might not be attractive and valuable enough for existing users to upgrade. Considering OCI Image-spec v1.1.0-rc.4 was released on June 23, ORAS as a client tooling implementation to comply with the latest release of OCI Spec, so we may need to consider prioritizing the OCI Image-spec v1.1.0-rc.4 support in the release plan. It will enable users to experience the latest functionalities of OCI Image Spec and enhance ORAS CLI v1.1.0.

I would recommend ORAS CLI maintainers @oras-project/oras-cli plan and create a v1.1.0-RC.2 milestone which focuses on OCI Image-spec v1.1.0-rc.4 support as described in #1009 and OCI Distribution Spec v1.1.0-rc.3 as described in #898 . This also relies on ORAS-go v2.3.0. We can discuss and confirm the ETA of ORAS v1.1.0-RC.2 in the next community meeting. The ETA of ORAS v1.1.0 could be planned two weeks later than v1.1.0-RC.2 for testing purposes.

If you agree or have different ideas on the two release plans above, please comment below. Thanks.

Last but not least, I opened a PR to clarify the release management process and release strategy, which includes release versioning, supported releases, and release process. I think it will help us unify and standardize the release management.

[yizha1]

Introducing necessary bug fixes from release-1.1 branch to the release-1.0 branch

Should the bug fixes be merged from main to release-1.0 branch?

[shizhMSFT]

For dev perspective, the steps to release v1.0.1 is

1. Merge main into release-1.0
2. On release-1.0, revert feat: add flag to skip deleting obsolete referrers index #957
3. Create a vote v1.0.1 PR targeting the release-1.0 branch

[FeynmanZhou]

Good catch. Merge main into release-1.0 should be the right option in this case if we agree on release v1.0.1. There are more bug fixes in the main branch when comparing with release-1.1 branch.

[TerryHowe]

SGTM

[qweeah]

SGTM

[sajayantony]

LGTM.

[shizhMSFT]

LGTM

[FeynmanZhou]

Close this issue since we have released ORAS v1.1.0