OpenVox platform support policy

[genebean]

Vox Pupuli has this a Software Support Lifecycle already that I think just needs a little polish to be applied to OpenVox as well. The tl;dr is that when the people who make an OS say it is End of Life (EoL), we don't support it any longer. This is tied to the general availability of the OS, not paid / special extended support.

Additionally, Vox has historically supported versions of Puppet that were still considered supported by Open Source Puppet (aka OSP). I think this is still the right path and we should support the same major versions of Puppet as Perforce does per https://www.puppet.com/docs/puppet/8/platform_lifecycle.html and similar pages for other Puppet versions. Furthermore, I think the OpenVox agent's major versions should also stay aligned here.

Barring significant disagreement, I will take the existing page and draft adjustments to it in a pull request to account for this. I will also add an alias / redirect within the OpenVox docs to the same page as part of the same PR.

Since we are not forging new ground here, I think the standard lazy concensus model applies wrt to timing of all this, plus I'd like to get it published before Config. Management Camp at the start of next month.

[genebean]

Expanding on this a tad, I think we should keep the existing platform support matrix with regards to OS and platform combinations, with the caveat of infrastructure to test on being available for each given platform.

[jstraw]

I agree with the OS and Module EOL lifecycles as described in the existing Lifecycle document.

I think we should not be locked to Perforce timings for how long OpenVox Puppet releases should live. I think we should define a minimum length of time for any Major version to be supported regardless of Perforce support.

Something like:

• 8 months of Feature Updates (total)
• 16 months of Bug Fixes (total)
• 24 months of Security Fixes (total)

With a major release once a year that gets to most-recent Ruby/JRuby and updates all the internals.

This would give us an overlap period of 4 months of bugfixes on 2 Major Versions, and only a maximum of 2 Major Versions alive at any time.

I think we also need to note that all of this is subject to change based on the Language Specification group defining how compatibility between OpenVox and Puppet is going to be described. I think we need to seriously consider a versioned Language and API spec separately from the OpenVox/Puppet versioning, otherwise we're going to still have to deeply coordinate changes between both parties.

[dhollinger]

With a major release once a year that gets to most-recent Ruby/JRuby and updates all the internals.

This would give us an overlap period of 4 months of bugfixes on 2 Major Versions, and only a maximum of 2 Major Versions alive at any time.

This would depend on how much we want to stick to SemVer as the versioning scheme. If we do, then Major version releases are only when the release contains "breaking changes". I'd vote we stick as close to that as possible since most of Ruby, OSP, and Modules utilize the SemVer standard.

[genebean]

I am fairly adamant that we adhere to SemVer. I really hate it when people don't do that.

[jstraw]

The thought I had was, we limit ourselves to EOLing Ruby and OS versions once a year, and do breaking changes together at that time.

SemVer is not negotiable for me either.

[anthonysomerset]

The thought I had was, we limit ourselves to EOLing Ruby and OS versions once a year, and do breaking changes together at that time.

SemVer is not negotiable for me either.

I concur with this approach, its often hard enough to track getting base OS' versions updated in good time, especially those in the RHEL camp and once you've got more than a few OS flavours in the wild adding this on time gets a bit onerous over time. I am presently tracking 19 different combinations of OS distro and major version at this time! but hey i love saying, hey we really need to get off Centos7 because not only is the OS EOL, but i can't enforce certain configuration compliances because puppet no longer supports it either :)

seperately, do we want to make any consideration to an "LTS" version that retains a slightly longer support time frame at least from a bug fixes perspective, e.g. i like how zabbix (and ubuntu) does this, where they cut a new LTS version periodically and this traditionally has much extended support while those that want to stay on the bleeding edge can upgrade to the interim releases, it gives a best of both worlds approach

[genebean]

seperately, do we want to make any consideration to an "LTS" version that retains a slightly longer support time frame at least from a bug fixes perspective, e.g. i like how zabbix (and ubuntu) does this, where they cut a new LTS version periodically and this traditionally has much extended support while those that want to stay on the bleeding edge can upgrade to the interim releases, it gives a best of both worlds approach

IMO, no for agent but yes on server & db. This would mirror what PE does (or did last I looked). They had 1 LTS build and more up to date build. I think doing the same here would be logical.

EDIT: no for agent in general except as needed to support the lts server.