[release-1.6] Release 1.6.3, second try

[mtrmac]

… after #1952 .

Cc: @lsm5 @jnovy

[lsm5]

I see: 1.6.3-maint -> 1.6.3 -> 1.6.3-maint. Shouldn't the HEAD commit be 1.6.4-maint instead? No strong preference though.

[mtrmac]

It was 1.6.2-maint before the recent #1952 ; so it should be 1.6.3-maint now.

OTOH it’s the only branch using the -maint name (it was requested in #1613 and we haven’t been consistent), and it’s clearly confusing. So if you think giving up and moving to 1.6.4-dev would be better, I’m perfectly fine with that.

Cc: @jnovy who originally objected to -dev in #1613.

[lsm5]

It was 1.6.2-maint before the recent #1952 ; so it should be 1.6.3-maint now.

OTOH it’s the only branch using the -maint name (it was requested in #1613 and we haven’t been consistent), and it’s clearly confusing. So if you think giving up and moving to 1.6.4-dev would be better, I’m perfectly fine with that.

Cc: @jnovy who originally objected to -dev in #1613.

Na, if @jnovy requested that then I'm fine with that.

/lgtm

[jnovy]

@lsm5 would it make sense to add -stable prefix in the stable branches? We had previous whines from customers why we ship "development" versions in RHEL. The -stable suffix will avoid that confusion. Thanks!

[jnovy]

btw. -maint is also fine

[lsm5]

@lsm5 would it make sense to add -stable prefix in the stable branches? We had previous whines from customers why we ship "development" versions in RHEL. The -stable suffix will avoid that confusion. Thanks!

hmm, was it that we tagged the wrong commit and that's why customers saw -dev ? If the right release commit is tagged, they shouldn't be seeing -dev. Or did you mean something else?

[jnovy]

$ skopeo --version
skopeo version 1.11.2-dev

[lsm5]

$ skopeo --version skopeo version 1.11.2-dev

did you build release-1.11 branch or v1.11.2 ? Asking because v1.11.2 has version/version.go set to 1.11.2:

$ git show v1.11.2
tag v1.11.2
Tagger: Lokesh Mandvekar <lsm5@fedoraproject.org>
Date:   Mon Apr 3 09:14:01 2023

Update golang.org/x/net to v0.7.0 to resolve CVE-2022-41723.
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEnjPdhwTMA+LeuE2aHB7dfMfDoN0FAmQq0SYACgkQHB7dfMfD
oN0amQ//ZhXfLqYUBKUdpjtU1jzqz6mbOuDLsfbDdf3d9YJcNuPHslZEPtWf5EiE
PjJV/R2FT3GNeCwJoV8TLZ2OKwSfugfJlEwbMEa2bLvgX6ldWGS2MYRQmfC7zC4q
obyPaGbCZI7oDJzPRwf5sUVYrGctAAytp9hWqdtC1Fv8NkaoXcFi0LLwu7FJUqDG
uqQMQgUYoSad7sAe+v4Gggq5a/n/6GjGIO7nhVALf7jh7FWSQPRBklkUh90iryBG
d7aY/NN0oyjMNzV6r6ue5duZiHHcETvHiLdKkBW12FtY1lQ+S0yXTp0a/Vi3bMUw
NU9E20MLFjOxA2RsEXn5RXqu0tsF3oaH9PNFOn5JbyPzDm/ChxPC0U9qp4ezsJ8J
PxM59aXICp9aGXVWJwQyHi7X+HhOm6L4gmKK7qzziEQJ8QmWJS6Qh72GIvKN/sWD
lS+ghljEeJ5sNmbj0IKHtk579LpOmHyBCnlONI3MugArTtEPByS4LN/xgXYgKD6F
TgoQjxr0/Xj868G3lFZKaTz2JyU6cEdKaWbF1FsFLmQw6G1g1pLWQTGHTzy5sIKd
jTBKlu6TpRkkPcRgDDTPwO88FaZDKVtrl7vl5XSvXuFCPLB5MA1WzZA+opIgT1e3
7SnN8h7UeT6wr+aURUmr/Irf2kA+Y/optLI6zoMTbVSM9oDmh/I=
=5ses
-----END PGP SIGNATURE-----

commit dc1e14f7a7974d6b4afeee2ba31b090512f493a8 (HEAD, tag: refs/tags/v1.11.2)
Author: Miloslav Trma<C4><8D> <mitr@redhat.com>
Date:   Fri Mar 24 17:45:36 2023

    Release 1.11.2

    Updates golang.org/x/net to v0.7.0 to resolve CVE-2022-41723.

    Signed-off-by: Miloslav Trma<C4><8D> <mitr@redhat.com>

diff --git a/version/version.go b/version/version.go
index f02ee4fe..23614f52 100644
--- a/version/version.go
+++ b/version/version.go
@@ -1,4 +1,4 @@
 package version

 // Version is the version of the build.
-const Version = "1.11.2-dev"
+const Version = "1.11.2"

[jnovy]

The above comes from the RHEL8.8 candidate build - we always build from stable/maint branches for RHEL. Note all of them currently contain -dev suffix which is confusing for customers.

[lsm5]

The above comes from the RHEL8.8 candidate build - we always build from stable/maint branches for RHEL. Note all of them currently contain -dev suffix which is confusing for customers.

@mtrmac @vrothberg I wonder if it's worth following a branching process consistent with that of podman along with similar branch names.

[mtrmac]

The above comes from the RHEL8.8 candidate build - we always build from stable/maint branches for RHEL

If RHEL is not consuming the tagged versions on the backport branches, which were tagged specifically to be built as bug backports, and RHEL is taking the latest commit from a branch regardless of a version tag, it would be a bit less work for us not to tag those versions in the first place…

---

I wonder if it's worth following a branching process consistent with that of podman along with similar branch names.

I seem to remember that’s what we intended to do, with the release-v… backport branches. Yet, clearly enough, Podman is now not using that scheme, and might not have been using release-v… ever(?). But then again, Buildah and c/storage do use release-v… branch names; and c/common uses yet another scheme.

I very much agree that consistency across the projects is valuable. I care comparatively very little what the scheme is, and I’m happy to conform to whatever scheme is decided.

Making it (ideally) automated, alternatively well-documented, or in the worst case “obvious enough” what the rules are would help, at least me personally, to avoid stupid mistakes that add more work for other people.

[jnovy]

Yes @mtrmac - once a branch becomes stable then only approved changes go in so we don't need tagging in stable branches if it makes your life easier.

[lsm5]

Yes @mtrmac - once a branch becomes stable then only approved changes go in so we don't need tagging in stable branches if it makes your life easier.

Ack, that's been true for podman, but not quite so for buildah and skopeo and other libs that @mtrmac mentioned. Fedora has built skopeo and buildah tags cut from release-X.Y branches as in the latest v1.11.2.

Might be better to convert this to a discussion if we need more eyes on this. And whatever is the outcome should probably be documented on the https://github.com/containers page along with the repos to which it applies.