New Database and Servlet Container support strategy

Development
1

Hi devs,

I’d like to discuss/propose a new strategy for Database and Servlet Container version support.

Rationale for change

  • MySQL is now removed from debian packages but we need to continue supporting it
  • We don’t have a clear strategy for non debian packages (Oracle for ex).
  • Debian package can lag behind and that depends on the individual package managers

Analysis

Strategy 1: Last stable + previous super stable (aka LTS):

  • Tomcat: stable = 9.0.x, lts = 8.5.x
  • Jetty: stable = 9.4.x, lts = 9.3.x
  • MySQL: stable = 8.0.x, lts = 5.7.x
  • MariaDB: stable = 10.4.x, lts = 10.3.x
  • PostgreSQL: stable = 12.3.x, lts = 11.8.x
  • Oracle: stable = 19.3.x, lts = 18.4.x

For stable and LTS:

  • Version must be available to all OSes (for ex for Oracle, version 19.5 is only available for Solaris ATM)

The hard part is choosing the LTS which is not always easy (e.g. Jetty, MariaDB, Oracle). So the strategy could be:

  • Closest previous version that is maintained (ie it has bugfix releases)
  • Been maintained for over a year or so
  • Free maintained releases (doesn’t require a paying contract)

Example for Jetty:

  • Central Repository: org/eclipse/jetty/jetty-distribution
  • 9.4.x started in 2016-06-03 and last release is 2020-05-21
  • 9.3.x started in 2014-09-24 and last release is 2019-11-05 (9.3.28)
  • 8.1.x last release is 2016-09-22
  • => LTS is 9.3.x (closest, maintained, maintained for more than 1 year)

Example of MariaDB:

  • MariaDB Server - All releases - MariaDB.org
  • 10.4 started in 2018-11-09 and last release is 2020-05-12
  • 10.3 started in 2017-04-16 and last release is 2020-05-12 (10.3.23)
  • 10.2 last release is 2020-05-12 so it’s also maintained
  • 5.5 last release is 2020-05-12 so it’s also maintained
  • => LTS is 10.3.x (closest, maintained, maintained for more than 1 year)

Example for Oracle:

  • Database Software Downloads | Oracle
  • Release Schedule of Current Database Releases
  • 19.3 is the last release for all OSes
  • 18.x is the previous one, supported till Jun 08, 2021
  • 12.2.0.1 supported till “March 31, 2022 with Limited Error Correction from Dec 1, 2020”
  • 12.1.0.2 supported till “Jul 31, 2022 with paid ES, ULA, or EBS waiver”
  • => LTS is 18.x (closest, maintained, maintained for more than 1 year)

Strategy 2: Follow Debian package manager selections (“stable” and “oldstable”):

  • Tomcat: stable = 9.0.x, lts = 8.5.x
  • Jetty: stable = 9.4.x, lts = 9.2.x <-----
  • MySQL: N/A <-----
  • MariaDB: stable = 10.3.x, lts = 10.1.x <-----
  • PostgreSQL: stable = 11.7.x, lts = 9.6.x <-----
  • Oracle: N/A <-----

Pros of strategy 1

  • More up to date, e.g. postgresql 12.3.x and 11.8.x vs 11.7.x and 9.6.x
  • Works even if there are no debian packages, e.g. MySQL and Oracle

Pros of strategy 2

  • Simpler since someone else is doing the selection work for you

Update Strategy

The work is to update the jenkins pipeline code.

Proposal A

  • Similar to POM dependency upgrades we need someone to monitor releases of supported DBs & servlet containers
  • Could be Ilie monitoring releases since it’s related to quality

Proposal B

  • Check every month for new releases (when final XS version is released)
  • B1- Could be part of Release Plan for final versions.
  • B2- Could be owned by an individual: Vincent or someone else

Conclusion/Proposal

I’m proposing to follow strategy 1 + B1 (I’m fine also with B2).

WDYT?

Thanks

1 Like
2

The options 1 and B1 look very good indeed.

Thanks,
Clément

3

I forgot to mention/tackle one aspect: the fact that we distribute a Debian distribution.

So there are 2 aspects.

  • If we take the examples above, do the versions we test/support match well the versions from “oldstable”, “stable” and possibly “testing”?
  • Debian is not our only distributions and following the debian versions is making us not test more recent versions that our users can use when they use the WAR or Docker distributions.

Debian versions:

  • Tomcat: oldstable = 8.5.x, stable = 9.0.x, testing = 9.0.x
  • Jetty: oldstable = 9.2.x, stable = 9.4.x, testing = 9.4.x
  • MySQL: N/A
  • MariaDB: oldstable = 10.1.x, stable = 10.3.x, testing = 10.3.x
  • PostgreSQL: oldstable = 9.6.x, stable = 11.7.x, testing = 12.3.x
  • Oracle: N/A

So this would mean missing testing Jetty 9.2.x, MariaDB 10.1.x, and PostgreSQL 9.6.x.

Personally I think it’s acceptable.

4

+1 for strategy 1, it will be more clear for everyone I think.
I don’t have a clear opinion for the update strategy both have pros and cons.

Re Debian, I think we should at least ensure when performing updates that we keep covering Debian “stable”, and if it’s not the case then best IMO would be to have a “Debian” configuration in our docker tests for covering stable branch of Debian.

5

Yes, we could add that in the testing strategy. I haven’t written that part yet but I’ll make sure to include it as it makes sense, i.e. if the version strategy above doesn’t cover the “stable” version of Debian, then to add a pipeline config for that version. Now in practice it shouldn’t happen often (but indeed in the examples above, there’s PostgreSQL 11.7.x which is not tested and that is currently the “stable” version for Debian).

EDIT: It also means a bit more work for part B, since it means checking the Debian versions. That’s a bit painful.

6

I’ll also add that we always use the latest bugfix version (i.e. only specify major and minor for the docker image tags).

7

1 looks OK in general, basically it’s a case by case choice of two versions to put in automated tests

Yes since we have many people using XWiki on Debian (30% using directly the XWiki Debian packages and many more installing more manually but still on Debian) we should ideally have tests for versions close to what can be found on Debian standard repositories (even only “stable” is always good as a target).

I’m not a fan of B1 and the “let’s put everything in the release process” logic. Note that those versions update should be done after a release and not before it.

8

Yeah, I’m not fully sure on that one. But if it’s not that we need to define who handles it. Any proposal?

Proposal B1 was to do it during the final release process but at the end, after the release is done. It had 2 advantages:

  • We have a process to know who does it and the responsibility is shared between all committers (which also ensures that all committers know about it which is always interesting)
  • We are ensuring it’s done just at the beginning of a new version which is the best place.
9

+1 for strategy 1 + B1 as well.

Thanks,
Marius

10

Status:

Note: A wiki macro has been created to display the list of tested versions, it’s at https://www.xwiki.org/xwiki/bin/view/Macros/ProductVersionMacro/

11

Addition to the process: