On 2013-30-08 6:31, Luke Kanies wrote:
On Aug 28, 2013, at 12:09 PM, Henrik Lindberg <[email protected]>
wrote:
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).
I can't quite tell what options you're proposing here. My recommendation is to
support a given version, and have some clarity on what versions it's compatible
with, so we can reasonably well judge if a module will work.
Then we give users the ability to specify version compatibility, with the
default being forward from a given version (e.g., if they say '3', we assume
it's also compatible with 3.1, and probably 4 unless we know 3 and 4 aren't
compatible).
That is, we have the language itself, the engine for testing compatibility
between modules and the language, and then a specification system for declaring
what compatibility concerns are. None of them should support multiple
versions, but some might need to understand compatibility between versions..
Does that make sense?
Yes, that makes sense. What I am asking is if we also want to be able to
tell if code makes use of features that are newer than what the user
would *like* to use. (My code has to work in both puppet 4 and puppet 3,
I am marking my module as requiring 3, now please tell me if I am using
any features from 4).
To support this, the runtime must know at which revision a feature was
introduced as opposed to just having all features of the current revision.
- 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.
