On Fri, Aug 30, 2013 at 9:24 AM, Henrik Lindberg <[email protected]> wrote: > 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).
I don't think this is particularly useful from the language itself. If you're operating in a heterogenous environment, then use CI to ensure this. As I did in the thread on lazy/eager parsing, I look to Python for guidance here. Within a major version, new language features are enabled on a per-file basis, with 'from __future__ import xxx' where xxx is the name of the feature you want, e.g., 'with_statement' or 'absolute_import'. This statement enables the new feature for one minor revision, and becomes a no-op (the feature is always enabled) in the next. So 'with_statement' was optional in Python-2.5 and mandatory in 2.6. This is a mechanism for dealing with language changes that might make previously-valid code invalid. In the case of 'with_statement', code that uses "with" as a variable name will fail to parse because "with" becomes a language keyword. The process of upgrading code, including using the cool new feature, looks like this: (code runs on Python <= 2.5) 1. Upgrade all users to Python == 2.5 2. Remove use of "with" as a variable name (code runs on all Python versions) 3. Add 'from __future__ import with_statement' and use the cool new "with" statements (code runs on Python >= 2.5) 4. Upgrade all users to Python == 2.6 5. Remove now-redundant 'from __future__ import with_statement' (code runs on Python >= 2.6) Between major versions (2.x -> 3.x), neither forward- nor backward-compatibility is expected. Where possible, the devs have used "from __future__" to ease users' burden, and there's also a "2to3" tool to convert code from one version to another, but a large body of code is pretty much doomed to *either* run on 2.x or 3.x. Given how difficult this transition has been for Puppet, Perl, and Ruby, let's try to never do this! I think that the "parser" config parameter in Puppet is similar to the 'from __future__' model, although it doesn't allow selection of particular features, and it applies processwide, rather than on a per-file basis. Both of those limitations are fine with me. The upgrade process to begin using features in the 8.0 parser, while Puppet-7.3 is the latest version, would be: (code runs on Puppet <= 7.3) 1. Upgrade all users to Puppet == 7.3 2. Remove all use of language features deprecated in Puppet-7.0 (code runs on all puppet versions) 3. Enable --parser=future, and use cool new features (code runs on Puppet >= 7.3) 4. Upgrade users to Puppet == 8.0 with --parser=current (code runs on Puppet >= 8.0) Note that this way, step 4 doesn't introduce any new language incompatibilities. Basically, this decouples upgrading Puppet (the language, which can bring coding headaches) from upgrading puppet (the system, which brings its own set of operational headaches). As to naming the revisions, I think "future" and "current" aren't very good names, and I don't think that versioning the language separately is a good idea. I also expect that any backward-incompatible changes to the language will increment Puppet's major revision number. So I would suggest naming the language revisions after the puppet major revisions, with the default being the current. So as of Puppet-7.3, I can write --parser=v7 (the default) or --parser=v8. Dustin -- 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.
