Baremetal Operator releases

15 views
Skip to first unread message

feruzjon....@est.tech

unread,
Jul 21, 2022, 4:45:09 AM7/21/22
to Metal3 Development List

Hi,
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.

We didn’t have many of our active maintainers yesterday on the call. As such, if anyone has any objections or suggestions to make, please reply on this email thread.

Tracking issue: https://github.com/metal3-io/metal3-docs/issues/71
Semantic versioning guideline: https://semver.org/

- Feruz

Feruzjon Muyassarov

unread,
Jul 21, 2022, 5:20:27 AM7/21/22
to Metal3 Development List
I forgot to ask. Do we want releasing ironic-image repository too?

- Feruz

Honza Pokorny

unread,
Jul 21, 2022, 5:51:24 AM7/21/22
to feruzjon....@est.tech, Metal3 Development List
> 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.

+1

feruzjon....@est.tech

unread,
Jul 21, 2022, 8:31:56 AM7/21/22
to Metal3 Development List
Sorry, I made a mistake regarding naming of release branches on my initial email. I just 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.  Basically, we will have release branches like below
                           
                            | Release | Branch Name
---------------------------------------------------------------
| Minor release |   v0.1.0   | release-0.1  |
| Patch release |   v0.1.1   | release-0.1  |
| Patch release |   v0.1.2   | release-0.1  |
| Minor release |   v0.2.0   | release-0.2  |
| Patch release |   v0.2.1   | release-0.2  |
| Patch release |   v0.2.2   | release-0.2  |

- Feruz

Zane Bitter

unread,
Jul 21, 2022, 1:00:57 PM7/21/22
to metal...@googlegroups.com
(I was on the call and am fine with the plan.)

On 21/07/22 04:45, feruzjon....@est.tech wrote:
> Hi,
> 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.

The tradeoff here is we have to keep track of what changes are in each
version (as opposed to designating a time in the release cycle when API
changes can land and a time when they can't), although I guess if we
just bump the minor version every time maybe it's not a big deal.

> To start with, our MAJOR version will be 0, until we feel that the
> codebase is stable enough for the production.

For the avoidance of doubt here... the codebase is plenty stable enough
for production. What is not stable is the API definition because we keep
adding stuff without bumping the version, so what we discussed was to
keep the release at 0.x at least until we have an API version that we're
committing not to change (presumably v1beta1).

> 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.
>
> We didn’t have many of our active maintainers yesterday on the call. As
> such, if anyone has any objections or suggestions to make, please reply
> on this email thread.
>
> Tracking issue: https://github.com/metal3-io/metal3-docs/issues/71
> <https://github.com/metal3-io/metal3-docs/issues/71>_
> _Semantic versioning guideline: https://semver.org/ <https://semver.org/>
>
> - Feruz
>
> --
> You received this message because you are subscribed to the Google
> Groups "Metal3 Development List" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to metal3-dev+...@googlegroups.com
> <mailto:metal3-dev+...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metal3-dev/fa9d5287-16de-4a37-a29d-00262c40fd80n%40googlegroups.com
> <https://groups.google.com/d/msgid/metal3-dev/fa9d5287-16de-4a37-a29d-00262c40fd80n%40googlegroups.com?utm_medium=email&utm_source=footer>.

Reply all
Reply to author
Forward
0 new messages