@dalen Unfortunately we still need to do our best effort to make stdlib 4.x work with Puppet 2.7 even though we said we'd be breaking backwards compatibility with the 4 major release.

The reason for this best effort is that we don't currently have an effective way to make sure modules that are compatible with Puppet 2.7 don't accidentally bring in the latest version of stdlib which would break compatibility with Puppet 2.7.

For example, on a Puppet 2.7 system, if an end user installs module "foo" from the forge and "foo" specifies a generic (not locked to a major or minor version) dependency on stdlib, then the latest version of stdlib will be pulled in, which will be incompatible with Puppet 2.7.

Until we sort out a way to resolve dependencies taking into account the base version of Puppet, then we need to be extra-careful about breaking compatibility with Puppet 2.7 even though we technically said we already did so in stdlib 4.

Does this make sense?

-Jeff