Update README and metadata to remove official PE and Puppet Core support

[nmburgan]

Pull Request (PR) description

Update the readme and metadata to show we can no longer support PE or Puppet Core

This Pull Request (PR) fixes the following issues

n/a

[nmburgan]

This will also remove the forge showing it is supported for PE, as it has an internal table it uses to map Puppet to PE support.

[nmburgan]

Note to reviewers: I will remove this before merging for now, until we've got the Facter fork ready and we're comfortable removing it.

[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