On Thu, May 17, 2012 at 9:55 AM, Brian Gupta <[email protected]> wrote: > On Thu, May 17, 2012 at 12:38 PM, Ryan Coleman <[email protected]> wrote: >> On Thu, May 17, 2012 at 9:23 AM, Brian Gupta <[email protected]> >> wrote: >>> Will general best practice for forge modules to be developed against >>> current latest puppet version, or maintain backward compatibility >>> going forward? e.g. - let's say there is a version of a module that >>> works with 2.7, when Telly ships will the plan be for the modules to >>> be required to support both puppet versions, or just Telly? Or are you >>> guys thinking that there will be separate modules for different >>> versions of puppet? (Perhaps you guys aren't there yet in your >>> planning?) >> >> I'd love to hear what the communities thoughts are here! :-) >> >> From my perspective, I think it's up to the module author to determine >> what their needs are and author modules accordingly. If they can only >> run 2.6 and want to author modules that aren't compatible with some >> aspect of 2.7, that's perfectly acceptable. They'll just need to >> specify that so those using 2.7 don't install a module that doesn't >> work for them. They'd have to re-evaluate their module when a new >> version (like Telly) ships. > > Ah I had envisioned that the long term plan was for there to be core > modules that were written with best practices and that unless you were > doing something really funky, they would meet most people's needs. > (Either through some sort of official process, or crowd-sourced > voting/rating/self-selection).
I can't speak of the precise plans, but in terms of verifying module compatibility with specific puppet version, I've found rspec-puppet to be really helpful. Rather than depend on some arbitrary meta-tag, it's much more reliable to have automated tests verify the module works with specific puppet version. In the puppetlabs modules that provide rspec-puppet tests, rake spec run will verify the modules not only compiles in your puppet environment, but the correct resources and relational dependencies meet the author expectation. >> I added a comment to that ticket suggesting an idea to take the burden >> of specifying compatibility off of module author. Perhaps for modules >> that provide spec tests, we could automatically test that module >> against a matrix of puppet, facter and ruby versions to set and >> maintain what the module is compatible with every time a new version >> of puppet or facter is released. Just a thought.. and certainly that >> could be optional to authors who would rather manually specify >> compatibility. > > Hmmm.. a thought (may be to much).. what if you also tracked > incompatible versions. That way if someone wanted to test it with a > version of puppet that the author didn't have an opportunity to test, > someone could submit a testing patch marking it as compatible or > incompatible with specific version(s)? Writing spec tests certainly puts a higher demand on module author, but I think it's really worthwhile. I would personally love to see puppet-lint, rspec-puppet, and in the long term maybe even acceptance test to validate different OS support and post those results in Forge rather than depend on a person to constantly keep up with new releases. Tim Sharpe who wrote rspec-puppet have an example for testing modules that's worthwhile as follow up reads: http://rspec-puppet.com/ http://bombasticmonkey.com/2012/03/02/automatically-test-your-puppet-modules-with-travis-ci/ Thanks, Nan -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
