On 2013-28-08 19:18, Luke Kanies wrote:
On Aug 28, 2013, at 9:05 AM, Ryan Coleman <[email protected]
<mailto:[email protected]>> wrote:
On Wed, Aug 28, 2013 at 8:04 AM, Henrik Lindberg
<[email protected]
<mailto:[email protected]>> wrote:
Questions
=========
* Do you think it is of value to have a "R3" language revision in
Puppet 4?
Would the language changes correspond to major.minor revisions in
Puppet? If so, keep in mind that very soon, module authors will be
able to express Puppet version support in module metadata which would
be available to other tools in addition to Forge.
Failing that, I'd welcome the addition of a new key/value in the
module metadata to cover the language revision expression. Feel free
to mail me off-list for more details on module metadata.
* 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?
For simplicity sake, why not keep the language version expression at
the module level and not allow one class in a module to use R3 and a
second class to use R6. This strikes me as complex without much
benefit. The module level should be granular enough IMO.
I agree wholeheartedly - we should never ship a release of Puppet that
supports more than one language version, we should just tell our users
whether a given module has stated incompatibilities with the current
version.
That is naturally the simplest to implement/support. This means a Puppet
4 can not tell you if the source is compliant with an older version/uses
any new language constructs (which is the feature we can support if we
want to) - i.e. "please ensure that I am not using features newer than
version x (we have that in production elsewhere and do not want new
features to sneak in yet)".
The same goes for modules; hey you have metadata that says you are for
revision R3 but not later, but you are using newer features. (This is
kind of difficult to do if only possible to validate against a singleton
version).
We would not however evaluate differently or support older versions of
functions, providers etc. This is only about understanding what the user
is saying in .pp files and if it is a valid program in the given
language revision or not.
OTOH - It simplifies the runtime if it does not have this ability. Users
that want to ensure backwards compatibility can use Geppetto which can
do this for them.
We should still have language revisions to enable tracking when features
where introduced and note so in documentation.
Also, if we only support "current" and "future" there is no need for any
additional flags nor does the language revision have to be exposed.
Does that change anything?
(I am fine either way, but if we want the more advanced option it is
more work to add it later - that is why I am asking).
- 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.
