Ooooooops.. Sorry 🫠

Just to confirm, I shouldn't merge anything for v12 until this is merged, and possibly something else is done?

and possibly something else is done?

What do you mean?

What do you mean?

Wasn't this PR for an already released v11.3.1? Did the tag need to be updated or something? 😅

Just checking if I should hold off merging anything or not 👍 So all good to go ahead and merge now?

We could now (without merging other things) delete the tag and release 11.3.1 again to fix the image. But the cleanest solution probably would be to release 11.3.2.

Ok, so another PR just like this one then, that bumps the version and gets released? Then after that I can merge my PRs? 😅

Yes. Or we leave it as it is. The only issue the current image have is, that update-check.sh thinks it's running on 11.3.0.
What do you think?

What do you think?

I don't mind either way. If you don't think it's worth the hassle, then I'll just start merging my PRs 👍

I didn't think of the update notification email, that will trigger now every time DMS is started.

Any idea, how to fix that (without reverting all your merges)?

Any idea, how to fix that (without reverting all your merges)?

I believe in private maintainer discussions we did plan how to approach such fixes.

If you fork the tagged v11.3.1 commit (or in this case the one with this update), you could add a new commit with the relevant updates and tag it for v11.3.2. This tag and branch would live off master though (and could probably be deleted at some point).

This branch won't be merged into master. (EDIT: It'd be technically required for the update checker)

Just name the branch release/v11.3.2 or something? When tagged, it should trigger the CI workflows that monitor for tagged commits. Tags aren't tied to branches, so they will bypass anything that normally relies on master branch updates. That should trigger the workflows to build and publish an image to DockerHub.

That said, I think we could release a v12 early Janurary? So the minor annoyance wouldn't last long.

Like this? I've also create a release draft. Can you check and confirm, everything is okay?

default_on_push.yml should run upon tagging the commit:

Building the image, running tests and then if both pass publishing the image:

During the publish workflow, it should apply the following image tags, and since we're not on master branch, the :edge tag is ignored (a workflow triggered by a pushed tag should always ignore that AFAIK, even if the commit is on master branch):

That said, these generic re-usable workflows may be a bit different and we may have to pay attention to what happens here:

As you can see that our default_on_push.yml on this branch does not run the generic_publish.yml I've shown above (with the old ARM support), but specifically the workflow from current master branch due to the @master at the end:

This will result in publishing v11.3.2 without legacy ARM platform support, something we intended to drop from v12 onwards. This is just due to the workflow changes, other master branch changes like TLS support shouldn't be applied if these workflows work as I expect them to :)

Other than the above, our docs likewise have production deploy workflow trigger by pushing tags:

No concerns with that, other than not being 100% sure if only the workflow is run from the master branch version, or if it ignores this branch/tagged commit and switches to master. I'm pretty sure that unlike workflows triggered by a workflow dispatch event, the initial context should be carried over, and our usage of these generic workflow files between master branch and PR branches/events should be a good indication of that.

Summary

• Tagging a commit on this branch will trigger an image build, test, followed by deploying to container registries.
• Docs will also be built and deployed for this tag.
• Concern: Workflows used are master branch copies, not workflows on the active branch? ARMv7 will not be published for this patch version.

I don't anticipate the concern to be a real issue, seeing as we're dropping support with v12, and if we have any such users, they can remain on v11.3.1 as they'd continue to receive update notifications going forward anyway (unless they opt-out via ENV).

I've also create a release draft.

You can make a release on Github I think, but we would not be tagging the usual master branch. Is this a branch / history you'd like to keep around going forward? Or do you just want to publish the change for users?

The branch could be merged into master afterwards to update the changelog and version (required for the update checking feature?). If you do this I think it should be a merge commit not our usual squash merge.

Although I'm not sure if that will help with commit history, I think Github would interleave commits by timestamps, so it would appear after v12 commits have been merged, and even with non-linear history views that show the commit connected to a merge commit, it's not likely to look any better 😅

EDIT:

Ah yeah, so you'd want to merge this into master branch despite that:

Personally, I don't think it's worth the hassle if we get v12 out early?

You're welcome to go ahead and try tagging the commit if @georglauterbach green lights it as well. I just don't see it providing enough value to do so, looks like it'll risk some confusion or bug reports that we could avoid.

Better to advise using the ENV support to opt-out of update checks until v12 release if it bothers anyone? We can re-open and pin the related bug report until then for other users to be aware of?

Personally, I don't think it's worth the hassle if we get v12 out early?

You're welcome to go ahead and try tagging the commit if @georglauterbach green lights it as well. I just don't see it providing enough value to do so, looks like it'll risk some confusion or bug reports that we could avoid.

I'm very sorry for the inconvenience I've brought up here; but I agree with @polarathene. I don't think it is worth the hassle when we bringt out v12 in January, which is rather likely if you ask me :)
But I'll not be in the way if the proposed solution fixes the issue easily and in a safe manner.

It was still productive to evaluate how well the project can respond to this sort of thing. In particular for version updates it's a bit problematic due to implementation of the update checking requiring a commit on master related to the version update 😅

The main concern was due to the breaking change introduced to CI image publishing though, so this approach may still be viable in future 👍

I've relayed the decision on the related issue, and re-opened / pinned it, plus revised the initial report (I don't know why the form outputs markdown code fences instead of actual markdown :( )

#2952 (comment)

if the proposed solution fixes the issue easily and in a safe manner.

Alright, before we maybe mess up even more, lets withdraw this. This was just an attempt for an easy quick fix.

I am fine with releasing v12 in January.