Process and rules to release changes for the official XWiki Docker images

Hi devs,

We have 2 options:
Option 1: Release changes to the official images whenever we make some changes that affect one of the official docker tags (the official images will get rebuilt using the same tags)
Option 2: Release changes to the official images whenever we release an XWiki version, i.e. whenever we update the official docker tags

My preference goes to option 2 because:

  • Eventually we’ll want to release the docker distribution as part of the XWiki release, as any other distribution so it’s best that even now we release themin sync.
  • We have a problem of where to put the release notes for the changes in the docker distribution. The only place we have right now is to put them in the XWiki release notes. We could invent a new place for them but I feel it’s best to have them in the XWiki release notes as it goes with the first point.
  • Inside the doc on xwiki.org for the Docker distribution, we also need to use the {{version}} macro for new stuff and I’m proposing to use the XWiki version for that. For example a change made in xwiki-docker that is released with XWiki 18.6.0 will get a {{version since="18.6.0"}} (no need to use the product parameter since it’s XWiki by default).

The only case when we should release a change earlier than along with an XWiki upgrade is when the official docker images are broken (not a functional change). When that happens we should release ASAP.

WDYT?

Thanks

Hi! +1 to add a rule in the Versioning page of the Doc Guide to mention to use the {{version}} macro with the XWiki version. Thanks!

Not sure I understand. You mean a special mention when documenting the XWiki Docker distribution? Asking because otherwise, we already have the rule you mentioned.

I guess most changes to the GitHub - xwiki/xwiki-docker: Dockerfile to build and run XWiki on docker · GitHub will impact all future versions on all branches. So the {{version}} macro will most probably always have several versions in such a case.

+1 for the idea of not rebuilding previously deployed versions (except in case of important bugfix, on a case by case basis, of course)

Yes. Example: https://www.xwiki.org/xwiki/bin/view/documentation/xs/admin/installation/methods/install-xwiki-docker/logs/

Yes, I’d like to add a specific note saying: “For the Docker distribution docs, always use the XWiki version (not a separate docker version) in the {{version}} macro”.

+1 with the same comment, “important bugix” to be discussed amount the committers, I’m not sure if we need a formal definition.

+1 I’m afraid option 1 involves to have separate RN for docker releases basically so better stick to standard releases.

I guess in such case we’d still need to perform a blog post / an announcement on mastodon? Note that it also means we’d “loose” previous release tags in such cases since we wouldn’t bump the version at all.

I don’t think we need that for fixes related to the development. Even for the case when the image is broken, I’m not 100% sure we need to do that. I’d do it only if we had some automated release process.

If you mean that users wouldn’t be able to use a previously broken image then yes they won’t be able to using a tag but that’s good. Also note that with docker you can use sha1, see docker image pull | Docker Docs

So I don’t see that as a problem at all.

BTW I’ve noticed something to discuss today:

The consequence is that the official XWiki docker image for XWiki 18.4.3 will have this new feature before XWiki 18.7.0 has it (since XWiki 18.6.0 was released a few days ago).

Since we don’t have the notion of release branches for xwiki-docker (all work is done on master) that’s something inevitable.

I remember I had checked for having branches when I first designed xwiki-docker but I don’t remember why I thought it wouldn’t work back then. AFAIR I followed the best practices. However, since the official image file points to git sha1, I don’t see why it wouldn’t work. I’ll do some research about this (checking GitHub - docker-library/official-images: Primary source of truth for the Docker "Official Images" program · GitHub).

For now, I’ll release 18.4.3 with the new change.