[WIP] Bump to v1.33.3-dev #5190
Conversation
As the title says. Earlier today, I created a release-1.33.2 branch with v1.33.2 in it. Here in the main branch, we still have 1.33.2-dev. We are using the release-1.33.2 branch as a temp branch to build a Buildah with just the bloat removal from Docker and Buildkit for Podman v4.8. That branch will no longer be used after that is vendored. This main branch will continue on with the development for Buildah v1.33.*. Once we spin v1.33.3 from here at a later time, we may need to handcraft the Changelog files. If others have different thoughts, please let me know. My other thought was to bump this branch to 1.34 but there didn't seem to be enough content to justify that. [NO NEW TESTS NEEDED] Signed-off-by: TomSweeneyRedHat <tsweeney@redhat.com>
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: flouthoc, TomSweeneyRedHat The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/hold Lets wait for others to review, should we make this |
|
@flouthoc I think we should keep the 1.33.2 branch as is and not update it unless we have some kind of bad error in Fedora that we need to backport for. For the main branch, I would prefer to keep this as 1.33.3-dev and continue 1.33 development on it. However, I can be talked out of that. |
|
@TomSweeneyRedHat I agree, then this PR LGTM. |
|
Why do we want to keep 1.33 development on main? Following semantic versioning implies that we cannot merge any features if you say we do another 1.33.3 next on main and this makes zero sense to me. In all our projects we always seem to bump the next -dev version to the next minor versions so I really do not see what that should be any different now in buildah. |
|
The benefits, at least in my sick and deluded mind, were not to have another branch hanging around, to avoid a bump to v1.34 that would have practically no difference in code over v1.33, to avoid updates to two branches for a few months, possibly, and to keep the main branch chugging along with Buildah v1.33.* development. So I'm happy to do whatever you all think is best. But at this point, we have two branches, which are 1.33.2. The 1.33.2 branch and main. Suggestions on what to do to move forward? |
|
Well, then don't branch just because there's going to be of a new podman release, and especially don't do it when there's no new bit of API that Podman started interacting with that means it won't still compile with the same version of buildah that the previous Podman release used. |
|
I wanted to get the latest Buildkit into Buildah and Podman. There is a significant size difference between the prior version and the latest, and we wanted to keep the release of Podman less bloated. That was the motivation and the clock was ticking loudly. "Rename release-1.33.2 to release-1.33, ...". I'm confused by this one, did you mean "Rename release-1.33.2 to release-1.34", or should I replace the existing release-1.33 with 1.33.2, and then kill 1.33.1 and 1.33.2? I think the cleaner thing to do, despite the small changes between 1.33.2 and main, would be to create a v1.34.0 release from main, and then bump main up to 1.34.1-dev. |
openshift-merge-robot
added
the
needs-rebase
|
PR needs rebase. 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. |
|
Closing in favor of #5222 |
As the title says.
Earlier today, I created a release-1.33.2 branch with v1.33.2 in it. Here in the main branch, we still have 1.33.2-dev.
We are using the release-1.33.2 branch as a temp branch to build a Buildah with just the bloat removal from Docker and Buildkit for Podman v4.8. That branch will no longer be used after that is vendored.
This main branch will continue on with the development for Buildah v1.33.*. Once we spin v1.33.3 from here at a later time, we may need to handcraft the Changelog files.
If others have different thoughts, please let me know. My other thought was to bump this branch to 1.34 but there didn't seem to be enough content to justify that.
[NO NEW TESTS NEEDED]
Signed-off-by: TomSweeneyRedHat tsweeney@redhat.com
What type of PR is this?
What this PR does / why we need it:
How to verify it
Which issue(s) this PR fixes:
Special notes for your reviewer:
Does this PR introduce a user-facing change?