In Puppet 4 the idea is to make "the future parser" the "current
parser". While it is possible to simply throw the switch, the future
parser currently transform the parsed result to what the old parser
produced - this to have identical evaluation (with all its quirks). As
seen in performance measurements this makes the future parser operate
much slower.
Thus a new evaluator is required - there is a partial implementation
available already.
When doing this work we have the opportunity to give users new
abilities. Instead of just having a current implementation of the
language and an experimental future we can support language revisions.
This means that users can cap the language revision if they want to
ensure that code does not use newer language constructs (i.e. assert
that user code is backwards compatible).
Unfortunately, the future parser is not 100% backwards compatible with
the latest 3.3.x version as it is slightly more strict, and also removes
quirks in the 3.3.x parser. However, it is capable of validating that
code should at least theoretically work (and then fail at runtime just
like in the current 3.x code stream if a 3.x runtime is used).
We currently have the setting "parser" that can be set to "current"
(i.e. 'latest released') and "future" (i.e. "latest experimental"). We
can now allow the user to specify a more precise language revision.
Proposal
========
We name the 3.x language revision "R3" which means that it will validate
all language constructs added in "4" as being in error, and it will do
its best in informing the user about warnings and errors of the 3.x.
constructs. Users use this to assert that their code is "backwards
compatible" in a general sense (even if runtime error may prevent the
same "R3" compatible source to actually run correctly) - we can probably
warn/error out on these constructs (e.g. interpolation of function call
such as "Hello ${get_name_of_world()}").
We then add a "R4" language revision which contains support for all the
things we add in "Puppet 4" (e.g. iteration/lambdas, heredoc, epp, etc.).
As we continue to add features to the language that are backwards
compatible we increment the minor number. I.e. "R4" is really "R4.0",
and we have a progression of "R4.1", "R4.2" etc. We bump the first
number when we introduce a backwards incompatible language change. For
some time puppet versions and language revision verions may go in
sync-step, but over time the language changes will taper off (i.e. will
as in "should" or we are not doing a very good job).
Now, the user can specify either "current" (the latest, i.e. "R4.0"),
"future" (which will be "R4.0" as well since we have no experimental
features in the first release), or "R3".
As a starting point, the language revision could apply to the entire
runtime, but it is probably of value to allow the runtime to parse and
validate differently per module. Modules should have the ability to
declare which language revision they require (and or a cap on the max
language revision that they work with). The runtime can then treat the
modules differently based on their requirements. The range definitions
already available in the module metadata for module dependencies could
be used for language revision as well.
Ideas needed
============
We need to define how module authors should deal with migration to newer
language revisions - what if they want to support multiple language
revisions (perhaps with degradation of features) with one and the same
module version? We would need to parse with the latest language
revision, the code would contain conditional logic based on a setting
(e.g. "if $::setting[parser] > 'R3' { new code } else {old code}" - but
how do we know which language revision to use in this case? Should it be
noted in meta data? Older versions do not have "parser" setting, and
puppet 3.3 only has "current" and "future".
Questions
=========
* Do you think it is of value to have a "R3" language revision in Puppet 4?
* Is it meaningful to have major.minor revisions, or is a single number
progression enough?
* Is the ability to allow different version per module overkill? (The
alternative is to fail if a module is not compliant with the stated
runtime language revision, or yet another alternative is to just try to
use it and fail - leaving the language rev dependency to be resolved
when adding modules.
* How should we handle "multi version compatible/conditional" modules?
Regards
- henrik
--
You received this message because you are subscribed to the Google Groups "Puppet
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-dev.
For more options, visit https://groups.google.com/groups/opt_out.
