Update README and to show we can no longer verify functionality on PE or Puppet Core

[nmburgan]

Pull Request (PR) description

Update README and to show we can no longer verify functionality on PE or Puppet Core

This Pull Request (PR) fixes the following issues

n/a

[genebean]

LGTM. FWIW, there is an archive of that page in case they pull it or change it:
https://web.archive.org/web/20250416004958/https://www.puppet.com/blog/open-source-puppet-updates-2025

[bastelfreak]

We also need a PR title that reflects this change. And we need to discuss if this is a major change or not. We usually did major releases for dropping a end of life puppet version.. And it would help if we would actually test against our facter version.

[nmburgan]

Good call. Yeah, we should figure out if we need to major rev it, and hopefully we can get a facter-new gem out soon.

[bastelfreak]

Next step for facter: finding a new name: OpenVoxProject/openfact#12

Afterwards we can release it. That shouldn't take too long.

• get name for facter
• release facter
• update and release rspec-puppet-facts to use our facter
• update and release openvox to use our facter

[jhoblitt]

The warning language is well phrased and appropriate.

[tuxmea]

Do we really want to annoy users by specifying that a module is no longer "supported" to work on PE/PC?
I would prefer to say that we "can no longer verify functionality on PE/PC" and that additional testing is required.

It sound less harsh and might motivate people to move from PE/PC to OpenVox.
If we just say "no support", people might not doing updates anymore or build something by themselves.

[nmburgan]

Do we really want to annoy users by specifying that a module is no longer "supported" to work on PE/PC? I would prefer to say that we "can no longer verify functionality on PE/PC" and that additional testing is required.

It sound less harsh and might motivate people to move from PE/PC to OpenVox. If we just say "no support", people might not doing updates anymore or build something by themselves.

To me, those two things are equivalent. I personally prefer the stronger language to make it very clear that if you run into a problem with this in PE/PC, there's probably not much we can do about it (guessing a solution without being able to test it is not a good strategy). I also think the stronger language would make people more likely to move to OpenVox in order to get support, but perhaps that's true. But I also take your point that it may lead to people sticking with an old version and never updating. If people would like the softer language, I can change it.

[sehrkamp]

Do we really want to annoy users by specifying that a module is no longer "supported" to work on PE/PC? I would prefer to say that we "can no longer verify functionality on PE/PC" and that additional testing is required.
It sound less harsh and might motivate people to move from PE/PC to OpenVox. If we just say "no support", people might not doing updates anymore or build something by themselves.

To me, those two things are equivalent. I personally prefer the stronger language to make it very clear that if you run into a problem with this in PE/PC, there's probably not much we can do about it (guessing a solution without being able to test it is not a good strategy). I also think the stronger language would make people more likely to move to OpenVox in order to get support, but perhaps that's true. But I also take your point that it may lead to people sticking with an old version and never updating. If people would like the softer language, I can change it.

I agree with Tuxmea, rather write something like "We can no longer verify functionality on PE/PC for licensing reasons. Additional testing will/could be required".
This will encourage more people to test the module and - perhaps - report the result instead of leaving it. Especially companies with larger or more extensive infrastructures will only be able to switch to OpenVox in the long term, even if they want to.

[binford2k]

I suppose we could even add a link.

Before using this module with Puppet Core, we suggest testing it yourself.

[tuxmea]

please use correct link: https://www.puppet.com/docs/pdk/latest/pdk_testing.html

[binford2k]

that's weird. It must have been an artifact of their docs system changes, because I copied that URL from a browser page.

[nmburgan]

@tuxmea @sehrkamp @binford2k @bastelfreak Changed the language.

[binford2k]

Suggested change

	## WARNING: This module is no longer supported for Puppet Enterprise or Puppet Core
	## WARNING: This module is no longer tested on Puppet Enterprise or Puppet Core

I think that I've come around to @tuxmea's suggestion. "Supported" is such an overloaded word, in some cases we use it to mean "this works on," in some cases we use it to mean "we've tested it on," in some cases we use it to mean "there's commercial support for," and so on.

Let's just be specific and say the accurate thing we're getting at.

[nmburgan]

Oops, I intended to but neglected to change the header :)

[nmburgan]

Fixed

[binford2k]

So here's a fun fact for y'all. If you remove puppet from metadata.json, the PDK shits its pants.

$ pdk validate
pdk (ERROR): Module metadata does not contain a "puppet" requirement.
$ pdk test unit
pdk (ERROR): Module metadata does not contain a "puppet" requirement.

And if you dare try pdk build then it tries to completely regenerate the metadata. I propose we add proper bounds instead. I'm ok with it in this PR or in a separate PR.

    {
      "name": "puppet",
      "version_requirement": ">= 7.0.0 <= 8.10.0"
    },
    {
      "name": "openvox",
      "version_requirement": ">= 7.36 < 9.0.0"
    }

[jhoblitt]

Could we start using the string openvox instead of puppet, since we will no longer be testing with "puppet"?

[binford2k]

@jhoblitt for the modules I'm working on right now, I added both. I updated my comment to represent that.