Define release guidelines for baremetal-operator and start publishing releases

[Arvinderpal]

We should adopt a releasing approach similar to that of CAPI and follow the well-known semantic versioning guidelines (see references below).

Besides this being a good practice, integration with the redesigned clusterctl will require that projects follow the above mentioned releasing strategy. A similar issue was created for capbm: metal3-io/cluster-api-provider-baremetal#224

PR Tracking:

• Makefile updates for docker build and push, and release manifests generation: Makefile updates for docker build and push, and release manifests generation. baremetal-operator#405
• ... #272

[metal3-io-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues will close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[dhellmann]

/remove-lifecycle stale
/lifecycle freeze

[metal3-io-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues will close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[metal3-io-bot]

Stale issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle stale.

/close

[metal3-io-bot]

@metal3-io-bot: Closing this issue.

In response to this:

Stale issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle stale.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[russellb]

reopened, since this is still relevant

[metal3-io-bot]

Stale issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle stale.

/close

[metal3-io-bot]

@metal3-io-bot: Closing this issue.

In response to this:

Stale issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle stale.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[fmuyassarov]

Reopening, since this has not been solved yet and still relevant

[Rozzii]

/triage accepted

[Rozzii]

/remove-lifecycle stale

[fmuyassarov]

Yesterday during the community meeting we discussed the process of starting Baremetal Operator project releases. We are going to follow the widespread semantic versioning scheme and since we have not yet announced BMO as stable we would like to have more frequent and smaller releases for now and when we reach the stability we would like to stick to the same release cycle as Kubernetes (3 times a year). But we will discuss it again when the time comes for that.

To start with, our MAJOR version will be 0, until we feel that the codebase is stable enough for the production. As such, we could start with MINOR version 0.1.0 and continue incrementing from there.

Main branch will be for development while release-MINOR.PATCH branch is for stable, tested and backwards compatible code. Whenever there is a new major or minor release, a new branch will be created with release-MINOR.PATCH name.

[s3rj1k]

@fmuyassarov major version 0 can be an issue for go.mod

Are we sure that that kind of release versioning will be compatible for go.mod usage?

[fmuyassarov]

What is the issue? We have been using it in CAPM3 until now.

[s3rj1k]

What is the issue? We have been using it in CAPM3 until now.

https://go.dev/doc/modules/version-numbers

Hmm, you are correct as per the link above.

I assume possible issue can be with v0 to v1 (creating a branch or subfolder)

[fmuyassarov]

What is the issue? We have been using it in CAPM3 until now.

https://go.dev/doc/modules/version-numbers

Hmm, you are correct as per the link above.

I assume possible issue can be with v0 to v1 (creating a branch or subfolder)

I don't see an issue in branching as well to be honest. But after your point, I realized that branch naming should not be release-MINOR.PATCH but instead release-MAJOR.MINOR because each MINOR can have 0,1,3..9 PATCH releases, and we don't want to create a branch for every single patch release. I will make correction on my email and thanks for pointing out.

[s3rj1k]

@fmuyassarov I was pointing out that go expects that new Major release should be in separate branch or subfolder and named as Major version value.

So transition for v0 to v1, according to golang spec, we would need to put newer code in new branch named v1 or into subfolder v1.

Not sure that this is actually needed for v0 to v1, pretty much sure that this is needed for v1 to v2 transition.

[Rozzii]

/remove-lifecycle stale

[metal3-io-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues will close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[Rozzii]

I would close this I think this issue has been resolved but please give your opinion.

[furkatgofurov7]

I would close this I think this issue has been resolved but please give your opinion.

+1

[Rozzii]

We have started releasing BMO and we have a release guideline in review metal3-io/baremetal-operator#1170.
/close

[metal3-io-bot]

@Rozzii: Closing this issue.

In response to this:

We have started releasing BMO and we have a release guideline in review metal3-io/baremetal-operator#1170.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.