This topic is quite actual and interesting also for me. I think PuppetLabs is following the first approach, and that's what I'm inclined to do. If it's well documented, metadata is correctly configured and SemVer has been explicitly followed, users should cope with it.
my2c al On Tuesday, June 30, 2015 at 4:10:22 PM UTC+2, Tom Limoncelli wrote: > > Suppose I maintain a public module. I'd like to start using some > Puppet 4.x language features. This means that anyone that uses this > module can't use the new version of the module until they also adopt > Puppet 4.x. > > What is the best way to address this? > > Some ideas that have been tossed around internally on my team: > > -- Increment the major version number and declare that 3.x users > shouldn't upgrade to the new major version. > -- Restrict our usage of the new features to ones that are compatible > with the "future parser" and assume that 3.x users will enable the > future parser. (This means more testing for us, which is difficult > since we don't want to maintain a Puppet 3.x master any in the > future.) > -- Change the name of the module and encourage Puppet 4.x users to > switch to the module name when they want the more advanced features. > (this seems like the worst option) > > I'm sure there are other options that we haven't thought of too. > > Is there a recommended process? > > Thanks, > Tom > > -- > Email: [email protected] <javascript:> Work: > [email protected] > Skype: YesThatTom > Blog: http://EverythingSysadmin.com > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/d53e9db1-1e11-49ba-88a1-f7e63fc4c73f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
