I wouldn't object to bumping the version to a major (3.x). There are enough changes, even if they are not that impressive to average users. That said, I have some questions.
- How could we do it? We cannot ignore the fact that we are 5 weeklies in after the changes have been merged. - If we go for 3.x, should we also change the versioning scheme? Can this come later? I think any discussions regarding versioning schemes should go together with a proper deprecation & removal policy. We could use this chance, for example, to say "we're removing prototypejs in 2 years, by version X". That's why I think it may be a bit out of scope for this discussion (IMO). On Friday, November 27, 2020 at 12:26:49 PM UTC+1 [email protected] wrote: > > > > I like the idea of the very clear dated releases. It makes support a lot > easier eg. "Oh your release was from november of last year, you should > upgrade" "okay, your using 2.65, when did that get released? oh 2 years > ago?" Like I never have to think when Ubuntu 20.04 came out, I know it was > more or less april of this year. The tricky thing is how would dates work > with LTS releases. It would be odd to have Jenkins 20201114-3 being > released in early 2021. > > > > I think a scheme similar as used for IntelliJ would work as well for us, > we can use weeks rather then milestones: year.week.patchlevel > I would not recommend to use the exact dates in the version as this is > harder to correctly write in bug reports. > > So 2020.30, 2020.31, and so on for the weekly releases, and 2020.30.1, > 2020.30.2, and so on for LTS release. > > > -- 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 on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/973dd22a-cc5b-4640-935c-f729ce6a2979n%40googlegroups.com.
