Take care in adding protocol version numbers that don't change often. TLS tried that and then implementations ignored the version field, so now there's an overly complicated handshake process to find the proper version to use.
On Fri, May 18, 2018 at 11:39 AM, nicolas de loof <[email protected]> wrote: > 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/je >>> nkinsci/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/ms >>>> gid/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/ms >>> gid/jenkinsci-dev/CANMVJz%3D9BjgA8OA%2B0Sg9HfToF2v5rueuVjHR1 >>> 28o41%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/ms >> gid/jenkinsci-dev/CA%2BnPnMzTWPTBy7QJ5jJkf6r3Jqd0Wc1vocoY_ >> 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/ms >> gid/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/CANMVJzkvC65VLSRTVprsmwcD9HPMe > mE2u4RtTSJxUzXgwjJxQQ%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJzkvC65VLSRTVprsmwcD9HPMemE2u4RtTSJxUzXgwjJxQQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Matt Sicker Software Engineer, CloudBees -- 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/CAEot4owSLPO4S%3DTZ4pRtia7rJm5L8RVDdaHHtkvbFs-NGwH0Kg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
