This will be a lot of work for our team - will move this to later on this fiscal year.

ElasticSearch went EOL some weeks ago (2017-01-16 [1]), which means the current MediaWiki LTS version now requires an EOL ElasticSearch :-(

Please re-consider the priority of backporting the 2.x support to the 1.27 branch!

[1] lifetime and EOL list for ElasticSearch: https://www.elastic.co/support/eol

changing the supported version of elasticsearch also means breaking support for everyone that already has elasticsearch 1.x installed, which seems opposite of what LTS means?

@EBernhardson - I don't think so, because ElasticSearch 1.x is EOL. Running EOL software is kind of... wrong. There no sense keeping back-compatibility with EOL software.

@FreedomFighterSparrow If 1.27 were a new LTS release starting around now, then yes, that would be wrong to support. However it is not a new release line. The 1.27 release line started back in September 2015.

Releasing a breaking change in a patch release (e.g. 1.27.3 to 1.27.4) is unacceptable. That would silently break many systems and goes against all sysadmin expectations.

While it is unfortunate that the ElasticSearch 1.x EOL was not foreseen when 1.27 was first drafted, there is nothing we can do about that now.

Looking at other products in the software industry (such as Ubuntu or Debian) it is quite common for LTS life cycles to provide "extended support" beyond the upstream EOL for some of the software they can depend on. It is not uncommon to see Debian or Ubuntu provide support (including security fixes) for software packages such as PHP and MySQL even after upstream declares a release EOL and no longer provides security fixes. Instead the packager then takes over the job of backporting patches for new security vulnerabilities. And regardless of whether they take over maintenance, they would never replace a package with a major newer version within the same LTS release cycle.

Adding optional support via run-time detection or a configuration option could be done, but it seems the current code base isn't built for that. This is something we could instead consider for the future, e.g. when ElasticSearch 3.x support is integrated, we could consider doing that in a way that supports both simultaneously, which would also make it easier to backport and provide to LTS releases.

@Krinkle, we're definitely not in agreement there - but I appreciate your thoughtful reply.

I can (and will have to...) live with running this single EOL software, as it only runs locally on my server without outside access, so not *much* chance of security holes.

When Debian/Ubuntu sticks to an older version to maintain compatibility, then they are also maintaining and supporting the other related components which rely on the older version. The MW development team is not supporting ES nor should they, so from that perspective I don't think it's a helpful analogy.

I think this issue might be a really good case for the MediaWiki Stakeholders' Group to pick up. The reason is, I think it's a reflection of how different WMF's use of MediaWiki is from third party enterprise use of MediaWiki. To elaborate, I'd venture a guess (happt to be corrected) that WMF are in complete control of their ES infrastructure, and that the MW instances they run are more or less THE major use case for ES. Outside in the wild however, it's pretty common for us enterprise MW users to have architectures where ES serves other systems apart from our MediaWiki instances. So if we try to stick to an obsolete ES version, it causes trouble because other non-MW ES users are using/expecting supported and more modern ES versions.

To walk a mile in my shoes, this issue is a lose-lose for me. I either have to inform colleagues that we unfortunately can't stick to a LTS of MW after all (which we REALLY want to do, the whole point of LTS), or that we'll need a legacy ES sitting doing its own thing in a dark corner somewhere.