We took this conversation to #puppet-openstack yesterday to discuss further.
*The problem:*
To summarize, with a Modulefile, we are able to specify release ranges:
1.2.x
We are looking for a similar capability for .fixtures to use for unit
testing.
Not being able to express the same in .fixtures.yaml forces us to either
have to pin specific tags (which requires frequent updates to fixtures
across several projects/branches), use master (which doesn't work b/c it
does not guarantee backwards compatibility and things are being
refactored), or target specific branches (which are not guaranteed to
exist).
In the longer term, the forge team is interested in creating major version
branches along with some timeframe for support (6 months). It would be nice
if major version branches were created when backwards compatibility for a
module is broken, but it may wind up being that just a selected subset of
modules will have maintained major version branches.
Since they are under-resourced given the large set of modules they have, it
is probably not reasonable to assume the existence of these for our
purposes.
The proposed solution is to allow for fixtures.yaml to consume desired
versions form the Modulefile, I haven't fully thought about the semantics
for it, but perhaps:
'mysql':
repo: 'git://github.com/puppetlabs/puppetlabs-mysql.git'
ref: Modulefile
When this is specified, it means that we should check the Modulefile in
order to determine how to get the correct revision for our module. (perhaps
in the future, this will be the default, and fixtures is only used for
overriding Modulefile defaults for unit testing)
Assuming the version from the Modulefile is a range, it would do the
following:
-- if a major release branch exists that matches the range, use it
-- otherwise, scan for what tags exist and use the latest tag that matches
the release range
Please feel free to comment, as the conversation this is based on was a but
hectic and ad-hoc.
On Mon, Sep 23, 2013 at 1:17 PM, William Van Hevelingen <[email protected]>wrote:
> Hi All,
>
ashp mentioned in #puppet that puppetlabs has not come to a decision on
> doing branches per major versions yet. This email is to help start a public
> discussion.
>
> The primary use case that I'm interested in is the Openstack modules as
> they rely heavily on the puppetlabs modules like apache, mysql, rabbitmq,
> etc.
>
> The 3.0 release of rabbitmq broke the openstack modules and CI testing for
> a while until bodepd pinned it to the 2.x release. This happened a few more
> times for other modules like the mysql and the apache module so bodepd
> ended up pinning all the module dependencies to a major version. I imagine
> some other large projects might have similar issues and hopefully they will
> respond to this thread as well.
>
>
> --
> Cheers,
> William Van Hevelingen
> blkperl on irc
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/puppet-dev.
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-dev.
For more options, visit https://groups.google.com/groups/opt_out.
