Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-42294

Declarative Pipeline needs a process for changing syntax

      If you look at the JobDSL project, they have a process by which the can change the syntax of their DSL, mark the old syntax as obsolete, notify user that the old syntax is obsolete, and eventually end-of-life it.

      We need the same thing for the Declarative syntax. We've already encountered something like this when we went from "stage 'name'" to "stage ('name') {}" in scripted, but this will come up again.

      We should not be locked into some part of the syntax forever just because it was in 1.0. At the same time, it should be possible to make changes that enable new syntax without breaking the existing syntax, and then later remove the old syntax.

          [JENKINS-42294] Declarative Pipeline needs a process for changing syntax

          Andrew Bayer added a comment -

          So we don't have a formal process for this currently, but my theoretical plan for this sort of scenario has been to keep both parsing/validation/runtime paths active with the old one printing out a message that it's deprecated and will be removed in a specific future release - i.e., not just "some day this will go away!" but "in release X.Y, this will go away!". That'll probably be the next major release - i.e., anything that we deprecate now wouldn't get removed until 2.0, but once 2.0 is actually in sight, we'll probably switch to not removing until 3.0, etc.

          Andrew Bayer added a comment - So we don't have a formal process for this currently, but my theoretical plan for this sort of scenario has been to keep both parsing/validation/runtime paths active with the old one printing out a message that it's deprecated and will be removed in a specific future release - i.e., not just "some day this will go away!" but "in release X.Y, this will go away!". That'll probably be the next major release - i.e., anything that we deprecate now wouldn't get removed until 2.0, but once 2.0 is actually in sight, we'll probably switch to not removing until 3.0, etc.

          Liam Newman added a comment -

          abayer
          That's sounds great. We should describe that in the project README, CONTRIBUTING, or other docs.

          How does this apply in the context of the RFC discussion in https://github.com/jenkinsci/pipeline-model-definition-plugin/pull/123 ?

          Liam Newman added a comment - abayer That's sounds great. We should describe that in the project README, CONTRIBUTING, or other docs. How does this apply in the context of the RFC discussion in https://github.com/jenkinsci/pipeline-model-definition-plugin/pull/123 ?

          Andrew Bayer added a comment -

          I don't think it really does there, at least not yet - agent naming (and naming of other extension point implementations) is a bit different than syntax changes due to relying on the Symbol mechanism rather than our own parsing logic. Plus I don't want to rename label in the first place. =)

          Andrew Bayer added a comment - I don't think it really does there, at least not yet - agent naming (and naming of other extension point implementations) is a bit different than syntax changes due to relying on the Symbol mechanism rather than our own parsing logic. Plus I don't want to rename label in the first place. =)

          Jesse Glick added a comment -

          FWIW I urged this to happen before 1.0 was released into the wild, so that we would require something like

          pipeline(1) {
            …
          }
          

          Compare Vagrantfile.

          Jesse Glick added a comment - FWIW I urged this to happen before 1.0 was released into the wild, so that we would require something like pipeline(1) { … } Compare Vagrantfile .

            Unassigned Unassigned
            bitwiseman Liam Newman
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: