While I agree with James' reasoning in theory, I see breaking JCasC as a
big deal. Even when we would be be able to compensate now in the plugin,
because that would leave several JCasC versions available that are known
to be broken on newer cores.
How about asserting JENKINS-58993 violation only during unit tests, so
we cause plugin maintainers to fix things before they hit people's
production (not in 100% of cases, I know)?
Also, I know I risk this was already discussed, but can we wrap the
whole milestone execution into Jenkins BulkChange so whatever saves will
be acted upon once the milestone is over?
On 20/11/2019 19.52, James Nord wrote:
> I will bite :)
>
> I would be -1 on that version.
> not having the fix in core is allowing silent corruption of
> configuration. knowing allowing silent corruption and doing nothing
> about it has no place to exist in code.
>
> It is not Jenkins that is blowing up but a plugin manipulating Jenkins
> state before it has been loaded causing race conditions and potential
> dataloss (infact I have observed data-loss which is why I wrote that
> defensive code to begin with)
>
> there have not been that many (as far as I can tell) reports of this, so
> I would say you can work around that in a plugin that at least means you
> are not susceptible to dataloss (at the expense of Jenkins startup time).
>
>
>
> On Wednesday, November 20, 2019 at 6:00:43 PM UTC, Oleg Nenashev wrote:
>
>
https://groups.google.com/forum/#!topic/jenkinsci-dev/O_g1kk39TBQ
> <
https://groups.google.com/forum/#!topic/jenkinsci-dev/O_g1kk39TBQ> is
> quite related to this thread.
> We might want to consider 2.198 as a baseline, just for discussion.
>
> On Wednesday, November 20, 2019 at 3:49:31 PM UTC+1, Oleg Nenashev
> wrote:
>
> 2.205 exploded due to
>
https://issues.jenkins-ci.org/browse/JENKINS-60199
> <
https://issues.jenkins-ci.org/browse/JENKINS-60199>, but IIUC
> it could be mitigated by upgrade guidelines.
> It discourages selecting 2.205 s the new LTS baseline anyway,
> IMHO needs more soak testing for other possible regressions
>
> +1 for 2.204. It has some negative community ratings, but I do
> not see particular issues in JIRA which would block it.
> All changes are relatively minor, and 2.203 ratings were fine.
>
> In 2.204 we would really want to have
>
https://issues.jenkins-ci.org/browse/JENKINS-59679
> <
https://issues.jenkins-ci.org/browse/JENKINS-59679> from Zbynek
> so that we can proceed with plugin documentation
> migration.without impacting UX for LTS users.
>
> Best regards,
> Oleg
>
> On Wednesday, November 20, 2019 at 3:05:23 PM UTC+1, Jesse Glick
> wrote:
>
> 2.204 sounds reasonable.
>
>
https://groups.google.com/d/msgid/jenkinsci-dev/a5f74add-9e84-4882-aad5-916b24064459%40googlegroups.com
> <
https://groups.google.com/d/msgid/jenkinsci-dev/a5f74add-9e84-4882-aad5-916b24064459%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
oliver