> 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.
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. On Tuesday, 3 February 2026 at 15:56:21 UTC Mark Waite wrote: > > > On Tue, Feb 3, 2026 at 6:50 AM 'Jesse Glick' wrote: > >> On Sun, Feb 1, 2026 at 4:50 AM Mark Waite wrote: >> >>> The second field of the version number would be the week of the year >>> >> >> This seems bizarre to me. Why not just use ISO-like dates, like Ubuntu >> and others? https://calver.org/users.html >> https://github.com/ducks/date-ver etc. give the idea. Jenkins 2026.04 >> seems self-explanatory. >> > > Your example seems to switch to a month based versioning scheme. That > could be a positive step as we could then choose the second Wednesday of > each month as the LTS release date, avoiding the calendar complications of > our 12-week LTS release schedule. > > How should we number weekly releases? How can we avoid confusion between > weekly and LTS releases? > > 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/54ff7661-5b6a-4408-b17f-c02ca4306370n%40googlegroups.com.
