Bump yum-epel version following testing

[chewi]

Tested as requested.

You will find that Berkself doesn't allow you to make this change without also changing the version number of ssmtp itself. It's debatable whether this is a bug. It should look at the local state of the cookbook but on the other hand, if you were to republish with the same version number, things could get messy.

I still stand by what I said earlier. I should have mentioned an even more important reason that if everyone were to pin back dependencies like this, we would end up in conflict hell. If the dependency were merely >=, it would be easy for an end user to pin back the version themselves in the event of breakage. To break free of a ~> restriction, they would have to fork the whole cookbook.

[drpebcak]

I understand your point, but on the other hand, it is a bit more complicated then that in general. For instance, the current version of the yum-epel cookbook depends on 'yum', '~> 3.0'. If something in yum were to change (like a major version release), yum-epel might break for some people unexpectedly. The version is pessimistically constrained to avoid that. I get that it means regular maintenance is required for it to stay up to date, but it also means that the version it is locked to is guaranteed to work with this version of the cookbook.

[chewi]

I think that yum-epel's restriction on yum is justified given their close relationship but I'm done debating this, there's only so much energy I can expend on a single line. 😁

[svanzoest]

👍 thanks for working with us on this. Much appreciated!