On Thu, Feb 5, 2026 at 12:38 PM Radek Antoniuk wrote: > 1. Where can I find the JEP for this, that explains pros, cons and > motivation of (i.e. what does Jenkins want to achieve with) this change?
There isn't a JEP for it yet. This discussion topic appears only on the Jenkins developer mailing list. The Jenkins developer mailing list thread extends a discussion that started at the Jenkins Contributor Summit on January 30, 2026 in Brussels. What we hope to achieve with the change: - It would indicate we made a significant change - It gives us a major release so we can actively promote the significant improvements to the Jenkins user experience that the UX SIG is currently developing - Administrators and users have a clear indicator of their version's age > 2. -1 for anything else than ISO-based dates, if any change is actually > needed. > Can you explain further exactly what you mean by "ISO-based dates"? The ISO-8601 standard offers many different formats for dates and a specific method for numbering the weeks of the year. However, the ISO standard seems to only use "-" separators between the elements, while the examples Jesse Glick linked often use "." separators. ISO-8601 allows ordinal dates which express the number of the year and the day of the year. Would you accept 2026-036 for a release delivered on 5 Feb 2026? Would you accept 20260205 for a release delivered on 5 Feb 2026? Is your intent that it should rigorously follow the ISO-8601 standard? If so, which part of the standard are you referring to, and why that specific part? Would you accept truncated representations (dropped after ISO 8601:2000), such as 25-02-05, for a release delivered on 5 Feb 2026? Several versioning implementations use variations of truncated representations (like Ubuntu's 25.04 and 25.10 releases). > > > I don't see the difference in marketing boost between 3.x and year based > version. In both cases, the users will see a significant change to the > version number and will evaluate the meaning of that significant change to > the version number. > > +100 > > > Moving to 3.0 would indicate to me a new major release, regardless of > knowing the current version number; whereas moving to 2027.1 I could assume > is just a standard incremental change from 2026.x > > Fully agree, this change seems confusing to me, hence I'd like to learn > more about the actual need/motivation. > > Motivation: When the new user experience is ready to be enabled by default, we can promote it more effectively than we've promoted other major changes, such as tables to divs, YahooUI removal, Spring Security 6.x upgrade, Java 11 support, Java 17, support, Java 21 support, and Java 25 support. Changing the version number format signals to users that Jenkins has made a major change. 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtGMyov4rZFyHxTs6G%2BUfBec5pa_r8J7t61rnfm-KS5Y0g%40mail.gmail.com.
