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?

-- 
Luke Kanies | http://about.me/lak | http://puppetlabs.com/ | +1-615-594-8199

-- 
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.

Reply via email to