How do modules plan on dealing with Puppet 3.x incompatibilities?

[Tom Limoncelli]

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: t...@whatexit.org Work: tlimo...@StackOverflow.com
Skype: YesThatTom
Blog: http://EverythingSysadmin.com

[Alessandro Franceschi]

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

[Kurt Wall]

On Tue, Jun 30, 2015 at 7:09 AM, Tom Limoncelli <t...@whatexit.org> wrote:

-- Increment the major version number and declare that 3.x users
shouldn't upgrade to the new major version.

I would adhere to semver and expect users to understand what that means.

It's a well understood convention/standard and doing anything else will violate

the principle of last surprise. 

Of course, you have to document and highlight

what gets broken.

Provid

​ing

​ ​

a deprecation

​ 

period, if possible,

​gives

 users 

a chance to test the changes

​.​

​

(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.)

​This pretty much implies your first option.

​

 

-- 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)

​Agreed.

K​urt

--

Don't believe everything you think.

[Hunter Haugen]

On Tue, Jun 30, 2015 at 7:51 AM Alessandro Franceschi <a...@lab42.it> wrote:

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.

Yep. The planned approach is to specify puppet 4.x (or whatever) in the metadata.json puppet requirement and major bump for semver.

We obviously can't just put a case statement around puppet-4 parser language, because the 3x parser will still barf on it even if the code paths would not be executed.

I would like to note that for functions/types/providers, we CAN get away with having conditionals on Puppet.version.to_f >= 4.0 as Ruby is Ruby and only the puppet APIs change between versions.

--
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 puppet-users...@googlegroups.com.
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.