On Wed, Mar 26, 2014 at 10:28 PM, Sean OMeara email@example.com wrote:
In the next few days, I’m going to push the 5.0 version of the mysql
It introduces some backwards incompatibility, so everyone make sure to
lock down to the 4.x series until you have a chance adapt your code.
It would be helpful to get a list of what backwards incompatible changes
have been made - reviewing a single huge commit with the changes makes it a
bit difficult to keep track.
The things that stood out to me were that recipe[mysql::ruby] is now gone
completely (does this functionality move elsewhere?), and a bunch of
parameters for driving mysql configuration have been removed, and many
resources will disappear from the main resource collection (as they’re now
in providers). What else have I missed?
In the mean time, I’m looking for testers and feedback.
- mysql is now a library cookbook - an example pattern for cross-platform
- user supplied configuration - minimal main configuration, with an
- Full RHEL, Debian, and Ubuntu, support.
- Illumos coverage for SmartOS and OmniOS
- tests, tests, tests, and more tests.
- tests are awesome
- expanded platform coverage is great
- I was initially turned off by the amount of repetition across the
providers and tests, though it does make it easier to follow when you’re
trying to understand the behaviour of a single platform
Now, negative feedback. This doesn’t look like a new version of the mysql
cookbook. It looks like a new cookbook that’s planning to kill the
existing mysql cookbook and steal its identity.
No matter what, refactoring recipes into providers would require a major
version bump - anyone currently reopening resources in those recipes will
need to find another solution for whatever they’re doing. I’m okay with
that. On the other hand, dropping support for the current attribute-driven
configuration is hard to forgive - and removal of the ::ruby recipe is so
gratuitous I’m wondering whether it’s actually an oversight.
It doesn’t seem right that every user of the mysql cookbook would need to
make changes. It would be useful to have a clear idea of which users will
need to - and I expect they would appreciate knowing why backwards
compatibility wasn’t possible for their use cases.