(MODULES-3354) Use 1.8.7 hash in validate_email_address function

[stbenjam]

Otherwise you get this on 1.8.7:

/usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require': /usr/share/foreman-installer/modules/stdlib/lib/puppet/parser/functions/validate_email_address.rb:2: syntax error, unexpected ':', expecting ')' (SyntaxError)
newfunction(:validate_email_address, doc: <<-ENDHEREDOC

[stbenjam]

There was another one recently in #598, rubocop can enforce a hash style if you wanted to do so on ruby code in this repo.

[bastelfreak]

Hi,
Ruby1.8.7 is EOL since a very long time. There are several open security issues that won't be fixed. Have you considered updating to a newer version? I know that RedHat still "supports" Ruby1.8.7 on RHEL6. But RHEL7 is out since years (and also ships an outdated version...), but still has a way newer version. Also puppet brings the AIO packages with a bundled Ruby version which even works on RHEL5 I think. A thrid option would be to package your own ruby, even this is easy.

---

I'm against this patch. Ruby1.8 restricts us from a developer side and is totally unresponsible from an Ops side. There are enough alternative solutions to get a newer ruby. Feel free to join #voxpupuli or #puppet on freenode and ping me there (or anybody else). We're happy to help you migrating to a newer ruby/OS/Puppet version.

[stbenjam]

I'm aware of all of this, but I don't need any help. Thanks for the offer.

Foreman and Katello project installers are puppet based via Kafo, and support system ruby on EL6 (the applications run inside much newer Ruby through software collections), and we utilize this module.

First, the hash style in stdlib is clearly hash rockets. If that changes, it should be changed it everywhere and be consistent instead. As it stands, the module is otherwise compatible with 1.8.7.

Second, this was introduced in a patch minor release and that's not an acceptable time to introduce such a change from a semver perspective.

I don't care if stdlib wants to drop 1.8.7 support, but it should be done appropriately.

[bastelfreak]

It isn't clearly defined in semver if increasing the minimum required version number of a dependency requires a major bump. We had a huge discussion about that in guard/listen#374, but I share you opinion. @hunner what do you think about a major bump in stdlib with official drop of ruby 1.8.7 and migration to the new Style/HashSyntax everywhere? I could provide a PR if anybody wants it.

[stbenjam]

It isn't clearly defined in semver if increasing the minimum required version number of a dependency requires a major bump.

That's fair enough, but it doesn't really appear the drop in 1.8.7 support was intentional, the doc hash was just overlooked. If it doesn't cost much to continue it working for 1.8.7, it'd be great if this was accepted like #548 was.

I'm very much looking forward to forgetting 1.8.7 forever, but unfortunately that's still some time away. :-\

[hunner]

@stbenjam Please be aware that we don't test on 1.8, code for 1.8, or claim compatibility/support for 1.8, which means any new module release could break on 1.8 again in the future.

stdlib's compatibility is currently based on puppet versions in metadata.json, not ruby versions. It currently claims compatibility with puppet 2.7.20 as a minimum, and 2.7.20 is ruby 1.9 compatible so doesn't imply ruby 1.8. I know this isn't very straight-forward, but I hope you can understand!

@bastelfreak I have definitely wanted to make a stdlib 5 release that drops puppet 2.7 but stdlib should really be the last one out the door as it is depended on by so many other modules.

[stbenjam]

stdlib's compatibility is currently based on puppet versions in metadata.json, not ruby versions. It currently claims compatibility with puppet 2.7.20 as a minimum, and 2.7.20 is ruby 1.9 compatible so doesn't imply ruby 1.8. I know this isn't very straight-forward, but I hope you can understand!

2.7.20 is also 1.8.7 compatible (and even 1.8.5, I believe haha), so one could argue it should support all the platforms that 2.7.20 runs on. Although, I realize these are both dead platforms for quite some time so one could also make different arguments.

It almost seems like metadata.json could use an understanding of ruby versions, as many modules ship ruby code in lib/.

Anyway, thanks! This keeps our ruby 1.8.7 party going on for a little while longer.

[hunner]

Yeah, metadata.json specifying ruby versions sounds like a reasonable feature.

Honestly the decision to support a ruby of 2.7.20 instead of all rubies is that we just don't have the internal bandwidth to handle the number of issues we were running into before we started dropping it. I'll bring up keeping stdlib for 1.8.7 as it should be "the last one out the door" as mentioned above, at least until 2.7.20 is out.