Switch jenkins.version recommendation to be 2.xxx.3 rather than 2.xxx.1 (except for latest line)

content/_layouts/corebaseline.html.haml

@@ -13,28 +13,7 @@ layout: developersection
     lts = site._generated[:core_tiers].stableCores
     oldest_lts = lts[0]
 
-    lts_1 = lts.select { |v| v =~ /[.]1$/ }
+    next_lts_1 = lts.select { |v| v =~ /[.]1$/ }[-1]
+    previous_lts_highs = lts.map { |v| v[0...-1] }.uniq[0...-1].map { |l| lts.select { |v| v.start_with?(l) }[-1] }
 
-    previous_lts_1 = 'undefined'
-    next_lts_1 = 'undefined'
-    # Iterate in reverse order over all split versions, and choose the first set of releases with at least 2 LTS.1 releases that are newer
-    # This attempts to balance wanting few implied dependencies, but also not requiring a very recent core
-    split_versions.reverse_each do |split_version|
-        lts_1_split = lts_1.select { |v| Gem::Version.new(v) > Gem::Version.new("#{split_version}.999") }
-        if lts_1_split.length > 1
-            # There are at least two LTS baselines newer than the split (current and previous) so this is a set of versions we can work with.
-            if lts_1_split.length == 2
-                # If there are just two baselines, recommend those.
-                previous_lts_1 = lts_1_split[0]
-                next_lts_1 = lts_1_split[1]
-            else
-                # If there are three or more (e.g. 2.249.1, 2.235.1, 2.222.1, 2.204.1, 2.190.1), recommend the most recent ones except the current (i.e. 2.235.1 and 2.222.1 in the example).
-                # So no recommended release will be newer than 12 weeks (unless there was a recent split) or older than 36 weeks (~8.3 months).
-                previous_lts_1 = lts_1_split[lts_1_split.length - 3]
-                next_lts_1 = lts_1_split[lts_1_split.length - 2]
-            end
-            break
-        end
-    end
-
-= page.content.gsub('PLACEHOLDER_NEWER_LTS_POINT_ONE', next_lts_1).gsub('PLACEHOLDER_OLDER_LTS_POINT_ONE', previous_lts_1).gsub('PLACEHOLDER_OLDEST_LTS', oldest_lts).gsub('PLACEHOLDER_OLDEST_WEEKLY', oldest_weekly).gsub('PLACEHOLDER_LATEST_SPLIT', latest_split)
+= page.content.gsub('PLACEHOLDER_NEWER_LTS_POINT_ONE', next_lts_1).gsub('PLACEHOLDER_RECENT_LTS_POINT_HIGHS', previous_lts_highs[-2...].join(' and ')).gsub('PLACEHOLDER_OLDER_LTS_POINT_HIGHS', previous_lts_highs[0...-2].join(' and ')).gsub('PLACEHOLDER_OLDEST_LTS', oldest_lts).gsub('PLACEHOLDER_OLDEST_WEEKLY', oldest_weekly).gsub('PLACEHOLDER_LATEST_SPLIT', latest_split)

content/doc/developer/plugin-development/choosing-jenkins-baseline.adoc

@@ -15,8 +15,12 @@ In particular, the LTS Release Line is based on slightly older releases to provi
 * *Building against recent Jenkins versions* allows you to use recently added core features and API from your plugin. 
 You will also use that newer version for `mvn hpi:run`, so it may be easier to test your plugin with newer Jenkins releases. 
 * *Do not use versions no longer supported by the update center*, which is currently anything older than PLACEHOLDER_OLDEST_WEEKLY for weekly releases, and PLACEHOLDER_OLDEST_LTS for LTS releases.
-* *Prefer ".1" LTS releases over weekly versions and later releases within an LTS line* for greater compatibility.
-  LTS releases with the same baseline usually don't have differences that would matter to plugin developers, and if they do, they may well behave differently on supposedly compatible weekly releases published shortly after the LTS baseline.
+* *Prefer an LTS version over weekly versions.*
+** If you are based on the _currently active_ LTS line,
+   try to stay on the first release in that line (2.xxx.1) unless you have a specific reason to depend on a subsequent micro release
+   (such as a need to test against a recently released security fix).
+** If you are based on a _historical_ LTS line (at least one release in a newer line has been published),
+   prefer to depend on the last release in that line (typically 2.xxx.3).
 * *Prefer releases that no longer result in implied plugin dependencies*.
   Sometimes Jenkins core features are moved into plugins, and any plugin with a dependency on an older core release will have an _implied_ dependency on the new plugin.
   This makes plugin management more difficult for administrators, so core dependencies should ideally be chosen so that there are no, or few, implied dependencies.
@@ -29,7 +33,9 @@ When updating the core dependency, choose the link:/changelog-stable/[newest LTS
 
 ## Currently recommended versions
 
-At the moment, the Jenkins releases *PLACEHOLDER_OLDER_LTS_POINT_ONE* and *PLACEHOLDER_NEWER_LTS_POINT_ONE* make good core dependencies unless there are specific reasons, like new features, to choose a different release.
+At the moment, the Jenkins releases *PLACEHOLDER_RECENT_LTS_POINT_HIGHS* make good core dependencies.
+You could also consider *PLACEHOLDER_NEWER_LTS_POINT_ONE* if there are specific reasons, like new features, to want something newer;
+*PLACEHOLDER_OLDER_LTS_POINT_HIGHS* would be reasonable conservative choices.
 
 ## Changing the minimum required version