Although I wrote that paragraph in the community page, it was never the intention to give the impression of a formal LTS system, more meant as an analogy to easier understand the release policy for that branch. So we should probably avoid the term LTS altogether. What about LTP "Long Term Patching", avoiding the word "Support" :)
-- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com > 28. aug. 2018 kl. 15:20 skrev Dan Untenzu <unte...@webit.de>: > > Hey Shawn, > > thanks a lot for your clarification, all questions answered. > > Your message should indeed find it's way onto the community page. > > Thanks. > > Dan > > Am 28.08.2018 um 13:18 schrieb Shawn Heisey: >> On 8/28/2018 2:59 AM, Dan Untenzu wrote: >>> I would like to get some feedback about LTS & EOL timeframes in Solr. >>> >>> The Solr website states that "6.4.x" is a LTS version and "7.x" is the >>> current mayor version (https://lucene.apache.org/solr/community.html). >>> >>> Question 1: Shouldn't it use "6.x", since version 6.6.5 is the latest >>> release of the 6 branch. >>> >>> Question 2: How long is the LTS timeframe - 6 / 12 / 36 months? When is >>> EOL of version 6.x? >>> >>> It would be nice to have some roadmap/timeframe on the download or >>> community page. Right now an admin can not tell whether they should >>> prefer the LTS over the mayor version, because maybe EOL of version 6 is >>> just next week. >> >> Here's the long-winded version of how things are done: >> >> I have never heard of any specific timeframes, and I have never before >> heard of any release being designated LTS. Releases are not made on a >> set schedule. Because of that, there is not a specific number of months >> that each release gets supported. >> >> The current stable branch is 7.x. Solr 5.x and earlier are effectively >> dead -- changes will not be made. The previous major version, Solr 6.x >> (specifically, the 6.6.x branch), is in maintenance mode, which >> basically means that there's a much higher standard for whether a >> problem gets fixed in that branch than there is for the stable branch. >> >> Problems in a 7.x version will only be tackled if they are problems in >> the *current* 7.x release. As of right now, that is 7.4.0. So if you >> find an issue tomorrow in version 7.2.1, a fix will only be found in the >> next release -- 7.5.0. If enough problems of the right kind are found >> after a minor (7.x.0) release, there may be point releases in that minor >> version, but normally once a new minor release is made, a previous minor >> release in the current major version will not be supplemented with point >> releases. >> >> Problems in 6.x must be problems in the current 6.x release, currently >> 6.6.5, and they must be either MAJOR bugs with no workaround, or a >> problem that is extremely trivial to fix -- a patch that is very >> unlikely to introduce NEW bugs. If a new 6.x version is released, it >> will be a new point release on the last minor version -- 6.6.x. >> >> When 8.0 gets released, 6.x is dead and the latest minor release branch >> for 7.x goes to maintenance mode. There is no specific date planned for >> any release. A release is made when one of the committers decides it's >> time and volunteers to be the release manager. >> >> The community page needs a bit of an overhaul so it says what I just >> told you. >> >> As for which release you should run ... typically that's the latest >> release. All releases are considered stable unless they are very >> specifically labeled ALPHA or BETA. Only two releases so far have ever >> had those designations -- 4.0-ALPHA and 4.0-BETA. >> >> I personally would avoid a new major version until a few minor releases >> are made -- so I would have no plans to run 8.0, but I might run 8.2 or >> 8.3. >> >> Thanks, >> Shawn >>
