Is this a limit with the current Windows installer we're using? Or is it a limit with all Windows installers?
On Fri, 6 Feb 2026 at 01:02, Alex Earl <[email protected]> wrote: > For the Windows versioning, here are the restrictions to version numbers > in the installer: > > "The first field is the major version and has a maximum value of 255. The > second field is the minor version and has a maximum value of 255. The third > field is called the build version or the update version and has a maximum > value of 65,535." > > Right now, we do the following encoding because of these restrictions: > > // C# code from the installer > var items = DisplayVersion.Split('.'); > if(items.Length <= 2) { // weekly release > int minor = 0; > if(items.Length > 1 && int.TryParse(items[1], out minor) && minor > > 255) { > EncodedVersion = string.Format("{0}.255.{1}", items[0], minor * > 10); > } else { > EncodedVersion = string.Format("{0}.0", DisplayVersion); > } > } else { > int minor = 0; > if(int.TryParse(items[1], out minor) && minor > 255) { > EncodedVersion = string.Format("{0}.255.{1}", items[0], (minor * > 10) + int.Parse(items[2])); > } else { > EncodedVersion = string.Format("{0}.{1}.{2}", items[0], > items[1], int.Parse(items[2])); > } > } > > 2.554 -> 2.255.5540 > 2.554.1 -> 2.255.5541 > > So, if we went to a date based version scheme, we may have to reverse the > fields in the version and recover that somehow. > > e.g., > > 2026.04 -> 4.0.2026 > 2026.04.1 -> 4.1.2026 > > The displayed version in the installer would be the correct version, it > would just be the installer version itself that would be "weird" > > We don't allow upgrading using the installer, so it shouldn't really > matter. > On Thursday, February 5, 2026 at 1:11:45 PM UTC-7 Mark Waite wrote: > >> 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/c61c4784-c167-4915-9695-90882c6dce12n%40googlegroups.com > <https://groups.google.com/d/msgid/jenkinsci-dev/c61c4784-c167-4915-9695-90882c6dce12n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAE1M8%2B9V%2Bw-e7JN9YC9_TP8hyW0LmzP%3D3FRKrvKgwtwGtFAXSA%40mail.gmail.com.
