How to handle updates?

[chrisburr]

Yes, I think it's early enough that you can bump the version in DIRACOS2 in the next patch release (I would not do it so > easily if it was production code, but as of now it's still experimental)

Originally posted by @fstagni in DIRACGrid/DIRAC#5000 (comment)

It doesn't need to be solved now but at some point we will have to decide how to handle "riskier" updates as in DIRACOS 1 we didn't have to care too much given how static CentOS 6 was. For example:

1. Updating the middleware XRootD/ARC/...
2. Updating other dependencies, gsoap/boost/...
3. Updating minor Python versions (these should be stable and fairly low risk)
4. Major updates, I have nothing specific in mind but imagine a siltation like Python 2 to Python 3

My initial thoughts:

0. We should avoid having active releases which cannot be used with the latest DIRACOS 2 version, especially considering there could be something like an "urgent" OpenSSL bug which requires everyone to update at short notice regardless of the DIRAC version they're running. I think this can be handled relatively by making sure that bug fixes for changes in dependencies target an appropriate branch.

1. As there aren't many downstream dependencies of things like XRootD (and I'm responsible for most of them) we can fairly easily control the versions we're given and rebuild older ones like XRootD 4.x if needed

2. Here we basically need to follow the "global pinning" in conda-forge but I don't expect this to be a problem. We might need to be careful with things like OpenSSL 3 when it's release but that migration will be relatively slow with both OpenSSL 1.1.1 and OpenSSL 3 being build for months so we will have time to run certifications with the new version.

3. Since Python 3.4ish these have been fairly stable. We might want to run a certification with the latest version but I don't think we should be too afraid of updates.

4. This would become DIRACOS 3 and we would likely need to support both DIRACOS 2 and 3 for a reasonably long time. Conda-forge would also likely support both variants for a long time so it wouldn't be a problem (this already happened for updating the C++ ABI and Python 2 -> 3).