Issue #20910 has been updated by eric sorenson. Status changed from Investigating to Closed Target version changed from 3.3.0 to 3.x
Un-targeting from 3.3.0 release; this work is all being tracked in JIRA ---------------------------------------- Bug #20910: Modules should be able to express language compliance levels https://projects.puppetlabs.com/issues/20910#change-95060 * Author: eric sorenson * Status: Closed * Priority: Normal * Assignee: eric sorenson * Category: * Target version: 3.x * Affected Puppet version: * Keywords: dsl parser * Branch: ---------------------------------------- Since we now have two parsers with different features they support, we need a way for authors of Puppet code to indicate what level of the language their code is written to. (In truth we have needed this since the first backwards-incompatible change to the language, but better late than never.) I feel pretty strongly that: - this should be expressed in a per-module level, with a 'global' default/override for site.pp and things imported there directly - it should be expressed in the modulefile / metadata.json along with the other dependency information about the module Additionally, Henrik has convinced me that: - compliance levels should be expressed as a simple monotonically increasing integer; feature flags are not necessary since there can't be the "mix and match" type behaviour you might see from, for example, different IMAP clients talking to an IMAP server. - a related mechanism with a set of key-value pairs where the keys are types of pragmas / validations and the values are severity levels (error, warning, ignore) -- this is implemented in the geppetto UI already (see attached). - there should be a 'wildcard' value (like 'future') that means "give me whatever you've got" for those who love the bleeding edge. To be determined: - a central 'registry' where each number of compliance is mapped to its rules/implementation (i.e http://www.iana.org/assignments/imap-capabilities/imap-capabilities.xml ) - what the metadata fields should be named - whether and how to expose them in the server and what to do when the minimum compliance level isn't met (i.e. https://github.com/puppetlabs/facter/pull/442 ) Some of this falls into the realm of the Forge/module ecosystem and some is in core puppet; I'll drive the decision making and implementation. It has to be in place before we make Future Parser the default or indeed before adding any more features to it. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" 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-bugs. For more options, visit https://groups.google.com/groups/opt_out.
