Puppet 5 deprecation

[bastelfreak]

This issue is a result of #228

Puppet 5 will be end of live soonish. In the past, when Puppet 3 and Puppet 4 were end of live, we removed them from the metadata.json. I propose we do the same with Puppet 5 now. Since our modulesync_config release 4, we generate our acceptance tests based on operating systems in metadata.json and the puppet versions in metadata.json. his means as soon as we drop Puppet 5 from metadata.json, we also stop running our unit tests on it.

Benefits:

• This would fix Ubuntu 20.04 tests where Puppet does not even provide puppet 5 packages anymore
• It's consistent behaviour with our Puppet 3/4 deprecation
• It won't encourage people to use outdated software

[bastelfreak]

@voxpupuli/collaborators please provide feedback :)

[logicminds]

My only concern is how do we release new major versions for all the modules? I would expect a major release for this type of change.

[bastelfreak]

I agree. A major release should follow (which we also did in the past).

[ekohl]

When we drop it, we need to figure out a new minimum version. I'd recommend Puppet 6.1.0 as a lower bound. This means we can drop the systemctl daemon-reload workaround that's present in various modules.

If we drop it, we should also drop any compatibility code that may be present. Otherwise that just sits there and complicates the module.

Some considerations:

• There is very little Puppet 5 compatibility code since 5 & 6 are largely compatible.
• It's not EOL yet
• Debian and Fedora native packages are still Puppet 5 and some people prefer those (myself included)
• Generally the extra CI is not that much overhead

That's why I'm in favor of holding off on dropping it in every module. I can provide a list of modules that I care about and will ensure they keep working on Puppet 5 if desired.

A good reason may be that a dependency has dropped Puppet 5 support, whether released or still in git. Perhaps we can automate that check somehow.

[crazymind1337]

Sounds good to me. 👍

[b4ldr]

As has said a major release would be warranted it would also be nice if we could create a branch before increasing the release e.g. puppet5.x. no commitments or modsync on this branch but it would make it a little easier for people who need to use puppet 5 for a little longer to contribute any critical fixes

[igalic]

As has said a major release would be warranted it would also be nice if we could create a branch before increasing the release e.g. puppet5.x. no commitments or modsync on this branch but it would make it a little easier for people who need to use puppet 5 for a little longer to contribute any critical fixes

this is kind of how we've dealt with 3.x

[ekohl]

We didn't do a puppet4 branch because the changes from 4 to 5 were so small.

[oranenj]

I'd prefer to leave Puppet 5 compatibility up to individual modules.

I would be okay with a policy where maintainers are free to add Puppet 6 -specific features if the module benefits from them, but I on't see much value in going through Voxpupuli modules explicitly making them incompatible with Puppet 5. While it'll be unsupported by upstream, it will still be found in stable distros for a long time; and as I previously mentioned, sometimes distro packages are the only option to install Puppet on a host.

[jhoblitt]

👍 I am generally in favor of a (current major release) + (current major release -1) support policy.

[SimonHoenscheid]

LGTM, We should have a look at modules where changes are in the pipeline which require a major melease to, and coordinate them together

[jhoblitt]

Of possible note, it appears that debian hasn't updated 4.x & 5.x packages to the latest upstream patch releases (stretch is still on 4.8.2 and buster is install on 5.5.10). I'm fairly skeptical that distros are going to put in the effort to backport security fixes. We should consider if we as a project are enabling this behavior.

[b4ldr]

Of possible note, it appears that debian hasn't updated 4.x & 5.x packages to the latest upstream patch releases (stretch is still on 4.8.2 and buster is install on 5.5.10). I'm fairly skeptical that distros are going to put in the effort to backport security fixes. We should consider if we as a project are enabling this behavior.

This is how debian , and many linux distros, work. They pick a stable release to use before going into a release freeze and then they backport and maintain all security/bug fixes. A better description of the process is here (this is ubuntu but the same or simlar holds true for debian, redhat etc)

[jhoblitt]

@b4ldr I understand the theory of how stabilized distro packages work. My point was that process appears to not be working for debian as they have not packaged the latest patch releases and I don't see any obvious back-porting. Nor is there, to my knowledge, any major effort to maintain major releases once they have been EOL'd by upstream that distros could draw from.

In took me only seconds to find known security issues with the debian packaged versions:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-7942
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-2295

Users are obviously free to chose any environment. However, if someone has chosen to use Slackware 1.01 and doesn't want to invest the effort to upgrade, it doesn't mean that this project should automatically try to support that decision.