Switch to year based version numbering

[Jenkins Developers]

During the 2026 Jenkins Contributor Summit in Brussels, Jan 30, 2026, one of the ideas that was discussed was a possible switch from 2.x based versions to versions based on the year of the release.  The second field of the version number would be the week of the year and the third field of the version number would continue to be the version number within the LTS baseline.

Some examples:

• 2.541 would be 2025.50
• 2.541.1 would be 2025.50.1
• 2.545 would be 2026.1

Benefits:

• Administrators and users have a clear indicator of the age of their version
• If we wait until the UX changes are ready (6 months or more from now), it would be a good indicator that we made a significant change, without the need to explain that we are not using semantic versioning

Challenges:

• Administrators with scripts that are hard coding 2. will need to adapt
• Window installer may need to map the new version numbers into the Windows installer version number limitations

Comments, concerns, and suggestions are welcomed.

Mark Waite

[Tim Jacomb]

I thought the proposal was the second number was just a release number which roughly maps to a week but we can and do sometimes release multiple versions in a week for a serious regression or for a release failure

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/jenkinsci-dev/a5d34387-9454-4a5e-91ac-3618d8dce398n%40googlegroups.com.

[Mark Waite]

On Sun, Feb 1, 2026, 12:30 PM Tim Jacomb <timja...@gmail.com> wrote:

I thought the proposal was the second number was just a release number which roughly maps to a week but we can and do sometimes release multiple versions in a week for a serious regression or for a release failure

Good clarification. You are correct.  The second number is a release number that resets every year. Roughly maps to week of the year

On Sun, 1 Feb 2026 at 10:50, Jenkins Developers <jenkin...@googlegroups.com> wrote:

During the 2026 Jenkins Contributor Summit in Brussels, Jan 30, 2026, one of the ideas that was discussed was a possible switch from 2.x based versions to versions based on the year of the release.  The second field of the version number would be the week of the year and the third field of the version number would continue to be the version number within the LTS baseline.

Some examples:

• 2.541 would be 2025.50
• 2.541.1 would be 2025.50.1
• 2.545 would be 2026.1

Benefits:

• Administrators and users have a clear indicator of the age of their version
• If we wait until the UX changes are ready (6 months or more from now), it would be a good indicator that we made a significant change, without the need to explain that we are not using semantic versioning

Challenges:

• Administrators with scripts that are hard coding 2. will need to adapt
• Window installer may need to map the new version numbers into the Windows installer version number limitations

Comments, concerns, and suggestions are welcomed.

Mark Waite

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/jenkinsci-dev/a5d34387-9454-4a5e-91ac-3618d8dce398n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bif4HSaSp922HKZW3-NVKQ7OrZyqXkJC1%2BE5GDU%2B%3DEpFMg%40mail.gmail.com.

[Daniel Beck]

> On 1. Feb 2026, at 10:50, Jenkins Developers <jenkin...@googlegroups.com> wrote:
>
> • 2.545 would be 2026.1

Since it's not actually weeks (otherwise we'd have trouble with re-releases :-) ), should this be 0-indexed?

Also, do we wait for shortly after NY 2027 to introduce it, and if not, do we skip a bunch of versions to align, or accept that for the first few months of the new scheme, versions will not be close to week of year?

> Administrators with scripts that are hard coding 2. will need to adapt

Also likely to have some impact on Jenkins project infra that deals with core versions we ideally prepare for (or fix up quickly afterwards).

I guess with Dependabot being on the decline, its special behavior for year version numbers (do not remember details, but IIRC it's what caused missed updated even before the recent regression) is unlikely to be a problem long term?

[Daniel Krämer]

Since it's not actually weeks (otherwise we'd have trouble with re-releases :-) ), should this be 0-indexed?

No strong opinion, personally I like 1-indexed better since our LTS releases are not being 0-indexed either.

 

Also, do we wait for shortly after NY 2027 to introduce it, and if not, do we skip a bunch of versions to align, or accept that for the first few months of the new scheme, versions will not be close to week of year? 

I don't think that we should be waiting for a new year but rather consider the changes we want to include with that version. We talked about the currently experimental  UI / UX changes and enabling them by default.

IMHO it would be good to not only have a new version scheme but also ship something new with it. A visual overhaul would be ideal here.

[Daniel Beck]

> On 2. Feb 2026, at 09:27, 'Daniel Krämer' via Jenkins Developers <jenkin...@googlegroups.com> wrote:
>
> No strong opinion, personally I like 1-indexed better since our LTS releases are not being 0-indexed either.

Might depend on the versioning scheme, but there's ambiguity when you have both 'X' and 'X.0', so the separate LTS release cannot really start at '.0'.

We also had 2.0.

> I don't think that we should be waiting for a new year but rather consider the changes we want to include with that version.

In that case, if we switch around July, should that release be 2026.0 (or 2026.1, see above), or 2026.27, and why?

[Daniel Krämer]

In that case, if we switch around July, should that release be 2026.0 (or 2026.1, see above), or 2026.27, and why? 

Personally I'd go with 2026.1 and start the first release of 2027 as 2027.1 and counting upwards until 2028, repeat.

Even though we could  make the minor version correlate with the week it has been released in I don't think we should do that really:

* first release of 2027 is likely not being shipped in the first week, so we already would have a gap / deviation from the start

* if we re-release or have multiple releases within a week we would have deviations

* if we skip a weekly release we would have gaps in our versions which I always find confusing

I'd just make it synonym for "it's the n-th release of a year" which would always be correct rather than "it was released in week N, or maybe a little before that".

[Jan Faracik]

Two cents on this based on our discussion on Friday. Agreed that a year based approach is the better long term solution, but I’d argue switching to 3.x is the better short term move. We need to agree what we’re doing this for - e.g. a marketing boost for the short term vs more sensible version numbers for the long term. I'd argue we'd benefit more from the short term boost than the long term, e.g. increasing/maintaining user base, increasing contributors for 2026/2027.