> 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).
Could we maybe keep the discussion here to just a 3.x bump as we are more likely to reach a consensus? we have tried and failed to get a deprecation policy for a long time - and I doubt we have enough time to do it before the next next LTS release changing to a different version scheme using YYYY.WW would still be possible after the fact as 2020 is > 3 should there also be a consensus in a follow up. > How could we do it? We cannot ignore the fact that we are 5 weeklies in after the changes have been merged. we just change the version in the weekly and say Hey we are calling this 3.1 and we are a little late. We do not have to be perfect /James On Fri, 27 Nov 2020 at 16:04, Victor Martinez <[email protected]> wrote: > +1 for the 3.x as a statement of intentions to the end users and +1 for > the time-based release versioning. > > > On Friday, 27 November 2020 at 12:03:21 UTC [email protected] wrote: > >> 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/341c82d4-1d1b-4886-a1c3-7e3b7ffa0c7an%40googlegroups.com > <https://groups.google.com/d/msgid/jenkinsci-dev/341c82d4-1d1b-4886-a1c3-7e3b7ffa0c7an%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 on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPzq3pfrqzQ3CL0dSeZ164TmCx1UytgOcKdbYq0%3DtQt1n%2BoJog%40mail.gmail.com.
