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

Update the layout documentation to reflect the current state #567

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 22 additions & 12 deletions site/LAYOUT.md
Original file line number Diff line number Diff line change
Expand Up @@ -84,31 +84,41 @@ It allows programmatically determining which versions of Jenkins get served whic

## Regular tiered update sites (LTS and weekly)

Directories with names containing Jenkins LTS baselines like `2.204` are version specific update sites.
The Jenkins update center provides multiple update sites.
Each of them only offer plugins compatible with the respective baseline, as well as the newest weekly or LTS release, depending on the variant (LTS or weekly).
This increases the usefulness of the update sites to users of slightly older releases of Jenkins, as they won't regularly be offered incompatible releases of plugins.

* `2.204/` contains the tiered update site for Jenkins 2.204 and _similar_ weekly releases not matching an LTS baseline.
* `stable-2.204/` contains the tiered update site for Jenkins 2.204.x.
---
**NOTE**: The update center used to support formats like `2.204/` and `stable-2.204/`.
This is no longer a case for the recent versions.
oleg-nenashev marked this conversation as resolved.
Show resolved Hide resolved

Each of these update sites only offer plugins compatible with the respective baseline, as well as the newest weekly or LTS release, depending on the variant (LTS or weekly).
This increases the usefulness of the update sites to users of slightly older releases of Jenkins, as they won't regularly be offered incompatible releases of plugins.
---

The Jenkins project publishes a limited, fixed number of tiered update sites to encourage users to regularly update Jenkins.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The number is dynamic, what's fixed (now) is how old the oldest supported release can be.

Directories with names containing Jenkins LTS baselines like `2.319` are version specific update sites:

* `dynamic-stable-2.319.1/` contains the tiered update site for Jenkins 2.319.x.

By default, the update center generates versions only for the first `.1` release of the LTS baseline.
We expect binary and API compatibility within the LTS baseline,
so it is extremely unlikety there would be a need for a specific update site for a `.2` release.
lemeurherve marked this conversation as resolved.
Show resolved Hide resolved
oleg-nenashev marked this conversation as resolved.
Show resolved Hide resolved

Structure of the update site:

```
2.204/
├── latestCore.txt (Unused, may be removed)
├── update-center.actual.json
├── update-center.json
├── update-center.json.html
└── updates -> ../updates
stable-2.204/
dynamic-stable-2.319.1
├── latestCore.txt (Unused, may be removed)
├── update-center.actual.json
├── update-center.json
├── update-center.json.html
└── updates -> ../updates
```

## Automatic redirects

By default Jenkins clients submit requests to the update centers with the `?version={JENKINS_VERSION}` argument.
It allows the update center to redirect the requests based on the version.

Redirect rules will forward requests to the top-level update site files to the most appropriate tiered update site, or `current/`:

* Releases older than the oldest supported baseline will be served the oldest update site (LTS or weekly).
Expand Down