-
Improvement
-
Resolution: Unresolved
-
Major
-
None
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.
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.