On Mon, Sep 2, 2013 at 12:40 PM, Henrik Lindberg <[email protected]> wrote: > How would you ensure this? The fact that it seems to work? Do you have > perfect test coverage? (The parser checks all code paths, not just the ones > that are executed in tests).
I'd run a copy of Puppet-7.3 and parse each .pp file. If it fails to parse, then it's not 7.3 compatible anymore :) > Maybe, although there is no definition of what "v8" is. That is only known > when v8 is released. I.e. the "v8" seen in 9x, is not the same as the v8 > seen in 7x. (I think it is better to have a symbolic version for > "future/experimental", and the "default/current". For users, shifting symbolic versions aren't much help - how do I know that, when upgrading to Puppet-8.0, what had been "future" is identical to "current"? That said, I'd be comfortable with the "next" version shifting slightly from release to release, as long as it is identical between the last minor release of a major version and the first release of a major version (that is, Puppet-7.3's "v8" should match Puppet-8.0's "v8", assuming there is no Puppet-7.4). This gives users enough overlap of parsers (Puppet, the language) to ensure code compatibility during the ugprade of the puppet system (puppet). > What we end up picking depends if there is any demand for the "validate > older versions"-feature or not. > > We could also offer multiple version support per module, but the runtime > would be at its pre-defined version (everything compiles to the same > catalog), we could however offer migration aid by allowing a module to stay > on an older version (thus missing features, but would also not be in > violation if, say, new keywords are introduced. This sounds horrendously complex, and I really don't see any value to it. There will always be system features (outside of the language) that modules require or conflict with, so advertising version compatibility is necessary anyway. If that also relates to language version, that's not substantially more difficult for module authors or users. > Hard to say what is most helpful and least confusing. While it may be > helpful to be smarter it may also give too many knobs to turn. I'm for clear rules that allow a simple, understandable implementation, even if that means that users and authors must do a little more legwork to keep up. > I am on the fence on this and like to hear what people think. I'd like to hear from others, too :) Shutting up for now, 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.
