There's still a few open loops in this thread that I'd like to keep pushing
on.
I admit I've been pretty adamant that there's real value for a) users,
operators, and ourselves, having an intuitive understanding of our
recommended upgrade paths by versions, and b) a method to reduce the CI
testing load, but it's also clear that the status quo isn't quite right yet
for all of us.
The topics I believe at hand are…
* Online versus Offline compatibility
* Testing resources required to community support many upgrade paths
* When deprecated cognitive load and tech debt does become too much
* What are we currently doing with Major vs Minor versions
* And, who are the people doing the work in these areas
I'm avoiding the marketing aspect of major versions. I think we need to
sort out and work forward from these technical issues first, but that might
just be my opinion 🤷
=Online versus Offline compatibility
There's a push to avoid unnecessarily breaking online and offline
compatibility. While offline compatibility has been deemed more
important, we should also aim to be online compatible forever. This raised
the tension point that no major, or any other, version should be a license
to break compatibility or remove deprecated stuff – we have leaned too
eagerly in this direction in 4.0 and 5.0.
=Testing resources required to community support many upgrade paths
=When deprecated cognitive load and tech debt does become too much
But we are fallible, there are bugs, accidental compatibility issues, a
build up of tech debt (cognitive load on compatibility paths), and limited
community resources to how much we can CI test, and limited doc
contributors.
I'm not keen on us recommending upgrade paths that we are not running
through CI. Neither having to rely upon downstream users and vendors
saying opaquely what is recommended.
This isn't an either-or situation. Let's target online compatibility in
the project, while being conservative in what we message publicly. For
example "these are our recommended upgrade paths, other paths may work but
you're on your own – do your homework".
Then, in the project when tech debt does become too much*, or there's
unintentionally breakage or a bug, we have possibilities at hand to make
fixes a little more feasible. And this should always be done with
consensus on the ML, and where breakages are restricted to non-recommended
upgrade paths.
*) I hope that removing tech debt (cognitive load) in the code is always
considered a valid discussion, and that we should keep in mind a codebase
that is also accessible to engineers that are not full-time employed to
work on C*.
=What are we currently doing with Major vs Minor versions
There is no desire for semver purity. The point is if/how we might take
advantage of the major and minor distinction. Some see it as an
opportunity for marketing. Some see it as an opportunity to reduce our
workload and cognitive load while making life a bit easier for operators.
And others see it as meaningless and should just be removed.
It has been suggested that our upgrade paths be restricted to those
versions we currently maintain. The problem with that is many operators
find themselves outside of these versions, and want to know what paths are
recommended or possible to get back onto a maintained version. We cannot
assume they can make a single jump back onto a maintained version, and
leaving them out in the cold is an unfortunate f** *** to them, IMHO. A
little empathy for our users goes a long way.
Documentation on our (recommended or strict) upgrade path should also be
available, but we don't see anyone really stepping on much on the docs
front. Again, I don't think it's appropriate to leave it to vendors to be
documenting this for us. The rule that we have "only upgrade between
adjacent major versions" has effectively/inadvertently been in place since
3.0 (and maybe 2.0 ?), and it is an intuitive and simple rule that avoids
us having to document much.
In an ideal world where we got good at always and forever maintaining
online compatibility, and had unlimited CI resources, we could remove the
need for this application of the distinction.
It's worth noting that our definition of compatibility can include both
hard and soft concerns. Hard is like 3.x to 5.x simply does not work
because internode messaging incompatibility. Soft concerns can be the jdk
version (we recommend the jdk upgrade happens separately to a major
upgrade), or like TCM where there's enough of an operational warning flag
that we would rather operators extra carefully check everything that must
be manually done.
=Who are the people doing the work in these areas
My argument has focused on the opportunity to reduce documentation
requirements, to make it that bit more intuitive for operators, and to
minimise the CI resources requirement while ensuring what we say we do we
test. I'm probably beating the dead horse here but I have had many
conversations with operators, with support, and also working on code inside
the project, which has benefitted from having a simple intuitive rule we
can rely upon.
So… IMHO anyone who wants to use major versions instead for marketing
purposes should be providing alternative suggestions that address the
raised issues, or stepping up to do the documentation, or donating the
extra CI resources needed. I'm so not keen on seeing it be undocumented
and yolo, "hey, go read the jiras, STFW…` – but maybe that is what the
vendors want ? I'm being a bit facicuous here, but the project is a
meritocracy that depends on people stepping up, I got my share of
frustration here.
Totally open to suggestions and new ideas, I'm not fixed on the status quo,
just keen to move it forward, working forward from the concerns and PoVs…
If pushed to make a call (prematurely) now, under the existing status quo,
my thinking is…
- Patience with bumping to 6.0, we are still a few months away from any
release
- Bump to 6.0 when we drop jdk11, if we agree TCM is a soft upgrade
incompatibility
- Continue to recommend that 4.x to 6.0 upgrades are not community
maintained nor tested
- Start enforcing unnecessarily breaking compatibility. Intentional
breakage and removals must always be ml approved
- Accept for now that community CI testing is limited to our messaged
recommended upgrade paths
- add additional upgrade paths if enough resources are available and
agreed upon
- if/when enough resources are donated discuss extending CI to test all
upgrade paths for all currently maintained versions
