Looking at this as someone who is more of a sysadmin(this is for the LTS
releases),
I like semantic versioning because  I want to know when an upgrade will
likely break things.
It gives me an idea of how much time I need to burn stuff in/warnings to
give and test before I promote from the testing environment.
That said, any pattern is workable, I would ask:
1) if you don't do semantic versioning don't make it look semantic
2) any breaking changes are very clearly communicated (if i'm going to jump
2 or 3 releases i'm going to at most skim the release notes)

Regards,
Beryl


On Thu, Nov 26, 2020 at 10:44 AM Baptiste Mathus <m...@batmat.net> wrote:

> TBH, I'd just embrace the more and more common yyyy-mm-dd ish pattern of
> releases.
>
> It would kind of make this clearer to outsiders that the version numbers
> of Jenkins are close to nothing related to stability but more a very
> regularly recurring release pattern.
>
> _Maybe_ I'd then agree with you for some new/adjusted version scheme *for
> LTSes*, but not worth doing this for weeklies IMO.
>
> It's *my* very personal opinion, fwiw.
>
> -- Baptiste
>
> Le mer. 25 nov. 2020 à 17:37, James Nord <jamestn...@gmail.com> a écrit :
>
>> Hi all,
>>
>> with the recent weeklies we have a couple of changes (Acegi
>> upgrade/table-to-div) that break compatibility in plugins.
>>
>> Whilst many open source plugins have been updated and made compatible
>> with the old and new version by the people making the changes (and
>> compatability layers have been added as far as possible), there can be
>> closed source ones that we have no sight of that can be broken.
>>
>> Given this is an API compatibility breakage, I am wondering why don't we
>> bump the version number to Jenkins 3.x  to signify the breaking API?
>>
>> Regards
>>
>> /James
>>
>> --
>> 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 jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/e58f72ae-ebc0-48dd-89f6-cb60f9ea0c85n%40googlegroups.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/e58f72ae-ebc0-48dd-89f6-cb60f9ea0c85n%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 jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS4jWRc3yfiyb_V9OJoVoXtGfBtWxfH5J58LL0rsz86jeA%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS4jWRc3yfiyb_V9OJoVoXtGfBtWxfH5J58LL0rsz86jeA%40mail.gmail.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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAKDA9fRDGBe8KQJHSzKy-cHfzJbsgZozMB76YvLKZhNnGZtmow%40mail.gmail.com.

Reply via email to