Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 6 commits into from
May 16, 2022
27 changes: 3 additions & 24 deletions content/_layouts/corebaseline.html.haml
Original file line number Diff line number Diff line change
Expand Up @@ -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_OLDER_LTS_POINT_HIGHS', previous_lts_highs.join(', ')).gsub('PLACEHOLDER_OLDEST_LTS', oldest_lts).gsub('PLACEHOLDER_OLDEST_WEEKLY', oldest_weekly).gsub('PLACEHOLDER_LATEST_SPLIT', latest_split)
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand All @@ -29,7 +33,7 @@ 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_OLDER_LTS_POINT_HIGHS, and PLACEHOLDER_NEWER_LTS_POINT_ONE* make good core dependencies unless there are specific reasons, like new features, to choose a different release.
jglick marked this conversation as resolved.
Show resolved Hide resolved

## Changing the minimum required version

Expand Down