To be honest, I can't see any benefit in short terms to introduce this just because at some time we might wish to change casc-plugin handling of _some_ metadata that would introduce a breaking change. At the time such a thing actually happens, we could easily introduce a top level "version: 2" pseudo-property so unlock such a breaking change (just like docker-compose did by the way). Or we can just have a 2.x branch for configuration-as-code plugin and keep 1.x for security fixes only. So that if you want your yaml config to rely on this, you just need to install 2.x plugin.
2018-05-18 18:09 GMT+02:00 Jeff Thompson <[email protected]>: > I agree on the value of having a version identifier. At some level, there > is a structure that may change, as anything tends to do over time. > Stephen’s description of a meta-schema version shows the existence of one > such structure. > > In my experience there have been times where I created a version > identifier for something and didn’t end up using it. But I can’t think of > an instance where keeping that at version 1 was ever a burden. There have > been other times where I didn’t add a version identifier and later wished I > had. And other times where I created one that I didn’t know I needed and > was later glad I had. > > Jeff > > > > On May 17, 2018, at 5:44 PM, Stephen Connolly < > [email protected]> wrote: > > But I still think you should include the (let’s invent a different name to > show the purpose) meta-schema version > > Most likely the meta-schema version will always be 1, but if you ever need > to revise then you will thank Jesse and I for suggesting it. > > CaaC has a schema for generating the schema at runtime... this is the > meta-schema... it says things like: Java Maps are represented by ____, use > the @Symbol as a ____, etc > > That is what the meta-schema version represents. If it changes then you > are saying the way of binding between yaml and runtime (in the general > sense) has changed. > > On Tue 15 May 2018 at 19:30, nicolas de loof <[email protected]> > wrote: > >> I've added a section on this topic in JEP-201: https://github.com/ >> jenkinsci/jep/tree/master/jep/201#versioning >> >> We can already generate a json-schema you can use to validate your yaml >> file(s) before applying configuration. >> What you miss is a tool to convert jenkins-core + plugins.spec -> json >> schema. >> This is something we could package as well (something comparable to >> jenkinsfile-runner) or even provide "as a service". >> >> We could also get such a tool both generate a schema and validate your >> config, as it seems there's not (yet) so much text editors to support >> json schema validation in yaml >> >> Would this help ? >> >> 2018-05-15 20:19 GMT+02:00 R. Tyler Croy <[email protected]>: >> >>> (replies inline) >>> >>> On Tue, 15 May 2018, nicolas de loof wrote: >>> >>> > 2018-05-15 0:20 GMT+02:00 Liam Newman <[email protected]>: >>> > >>> > > >>> > > Putting all that aside (as that is not the original point of this >>> thread), >>> > > the original suggestion was to include a version field in the CasC >>> YAML. >>> > > You said it would not work because the version would have to take >>> into >>> > > account the core version and versions of all plugins, otherwise it >>> might >>> > > break. Does that mean the CasC YAML could break _any time_ I >>> upgrade any >>> > > component? Doesn't that rather defeats the purpose of CasC? >>> > > >>> > >>> > Yes indeed. CasC doesn't have it's own model, everything is based on >>> actual >>> > java code discovery at runtime. So upgrading core or any plugin is >>> changing >>> > this model. CasC targets reproducibility and immutability use-cases. >>> If you >>> > want to upgrade anything you need to test it before. >>> >>> >>> Testing of changes between plugin versions was something I had great >>> difficulty >>> with for Groovy-scripting-based configuration, which was much more >>> common prior >>> to Configuration as Code. Do you have suggestions for administrators >>> such as >>> myself on how I might validate that my configuration YAML is >>> correct/applies >>> between any core or plugin upgrades? >>> >>> This gets to the underlying concern I had in mind when starting this >>> thread, as >>> an administrator, how will I know that my configuration applies correctly >>> between any core or plugin upgrades? My initial thought was >>> schema-versioning, >>> but I'm certainly open to other suggestions. >>> >>> >>> >>> Cheers >>> >>> >>> -- >>> 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/20180515181926.GB3395%40grape.lasagna.io. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> -- >> 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/CANMVJz%3D9BjgA8OA%2B0Sg9HfToF2v5rueuVjHR128o41% >> 3D3cU056g%40mail.gmail.com >> <https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJz%3D9BjgA8OA%2B0Sg9HfToF2v5rueuVjHR128o41%3D3cU056g%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- > Sent from my phone > > -- > 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/CA%2BnPnMzTWPTBy7QJ5jJkf6r3Jqd0Wc > 1vocoY_uP-kB6eUCnwPw%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMzTWPTBy7QJ5jJkf6r3Jqd0Wc1vocoY_uP-kB6eUCnwPw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > > -- > 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/62706E58-FC39-48C2-9A80-88A80F3FBBBC%40cloudbees.com > <https://groups.google.com/d/msgid/jenkinsci-dev/62706E58-FC39-48C2-9A80-88A80F3FBBBC%40cloudbees.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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/CANMVJzkvC65VLSRTVprsmwcD9HPMemE2u4RtTSJxUzXgwjJxQQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
