On Wed, Mar 14, 2018 at 1:55 PM, R. Tyler Croy <[email protected]> wrote: > core and plugin upgrades can result in > modification of config.xml and other object-serialized-files on disk when an > upgrade occurs.
Does happen, but rarely. In most cases, format changes take effect on disk only when a `Saveable` object is in fact saved for some other reason—a *Save* button in the UI, for example. > This means an upgrade of Jenkins Essentials has a very real potential to cause > irreversible modifications to files on disk which prevent a safe rollback. This is true. > "bricking" a Jenkins Essentials instance is a severe failure for the project This is what needs to be defined much more carefully. What would cause an installation to be “bricked”, exactly? Years of work by core devs (see JIRA issues with label `robustness`) have solved most cases where Jenkins would fail to start or be used in a basic capacity merely due to unreadable configuration files. You might get *Discard Old Data* warnings, of course, but these are not fatal. > we need to prevent against irreversible modifications to files causing > runtime failures That is a much broader requirement, at least if “runtime failures” could be interpreted as things like “the deployment stage in all my pipelines started failing”, and it is not clear to me that the proposal as it stands comes close to satisfying it. -- 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/CANfRfr2-jQ7HgKteHX%3DvyqPrCEHATD-q2QJwqE8ggJOYM%3D6Bcg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
