For those who don't know, we currently keep our puppet module versioning
linked to the foreman release. With the 1.3 release approaching, there
are a lot of version bumps in the puppet modules. So puppet-dns goes to
1.3 while very little has changed1. To solve this, I'm suggesting we
adopt semantic versioning2.
This is also important for forge users who may see a new version of
puppet-dns, look for changes and find out we've wasted their time
because it's an empty bump.
There's obviously a downside here since it will make it harder to find
out which modules you need for a particular foreman version. However, I
don't think this is a big issue because so far I've always used the
latest master modules in my production environment and we keep a focus
on making it possible to use older foreman versions by tweaking
parameters. We may need to put even more focus on this by documenting
supported foreman versions in the README.
All in all I think this is an improvement, but I could be missing
downsides. Given we're already quite far in the 1.3 cycle, I'm proposing
to adopt semantic versioning directly after foreman 1.3 has been
released.
I'd like to try this, so yes, good idea. Hopefully we can keep track of
it all.
···
On 12/09/13 14:39, Ewoud Kohl van Wijngaarden wrote:
> Hello all,
>
> For those who don't know, we currently keep our puppet module versioning
> linked to the foreman release. With the 1.3 release approaching, there
> are a lot of version bumps in the puppet modules. So puppet-dns goes to
> 1.3 while very little has changed[1]. To solve this, I'm suggesting we
> adopt semantic versioning[2].
>
> This is also important for forge users who may see a new version of
> puppet-dns, look for changes and find out we've wasted their time
> because it's an empty bump.
>
> There's obviously a downside here since it will make it harder to find
> out which modules you need for a particular foreman version. However, I
> don't think this is a big issue because so far I've always used the
> latest master modules in my production environment and we keep a focus
> on making it possible to use older foreman versions by tweaking
> parameters. We may need to put even more focus on this by documenting
> supported foreman versions in the README.
>
> All in all I think this is an improvement, but I could be missing
> downsides. Given we're already quite far in the 1.3 cycle, I'm proposing
> to adopt semantic versioning directly after foreman 1.3 has been
> released.
I'd really like to use librarian-puppet for this in future [1]. I tried to use
it for new installer but we should first make sure dependencies are set
correctly in our modules. With this, we could just distribute Puppetfile with a
particular foreman release. And also we wouldn't have to track all
dependencies in foreman-installer repo, just those we want to install. Their
dependencies would be resolved by librarian-puppet.
I think the two proposals are orthogonal, but sure, we can consider this
too.
How do you see package builds work? We'd run librarian-puppet during
the package build, or would we supply pristine sources for each of the
modules that we'd be using and combine them? I can't see this working
at runtime, that's all.
···
On 16/09/13 07:10, Marek Hulan wrote:
> On Sunday 15 of September 2013 20:44:15 Greg Sutcliffe wrote:
>> I'm fine with giving this a go during the 1.4 dev cycle.
>
> I'd really like to use librarian-puppet for this in future [1]. I tried to use
> it for new installer but we should first make sure dependencies are set
> correctly in our modules. With this, we could just distribute Puppetfile with a
> particular foreman release. And also we wouldn't have to track all
> dependencies in foreman-installer repo, just those we want to install. Their
> dependencies would be resolved by librarian-puppet.
I think we should have the modules code in our git just as a regular code. I
think we don't have network access during packaging process so we would have
to supply sources as you suggest. And definitely it should not be used at
runtime. It's just a tool for version and dependency management so we don't
need subtree or submodules. The packaging would remain the same I guess.
···
On Monday 16 of September 2013 09:28:27 Dominic Cleal wrote:
> On 16/09/13 07:10, Marek Hulan wrote:
> > On Sunday 15 of September 2013 20:44:15 Greg Sutcliffe wrote:
> >> I'm fine with giving this a go during the 1.4 dev cycle.
> >
> > I'd really like to use librarian-puppet for this in future [1]. I tried to
> > use it for new installer but we should first make sure dependencies are
> > set correctly in our modules. With this, we could just distribute
> > Puppetfile with a particular foreman release. And also we wouldn't have
> > to track all dependencies in foreman-installer repo, just those we want
> > to install. Their dependencies would be resolved by librarian-puppet.
>
> I think the two proposals are orthogonal, but sure, we can consider this
> too.
>
> How do you see package builds work? We'd run librarian-puppet during
> the package build, or would we supply pristine sources for each of the
> modules that we'd be using and combine them? I can't see this working
> at runtime, that's all.
Most of our modules are not managed by us, so we can't just add the
source into the foreman-installer repo without causing duplication and
not being able to merge upstream changes.
I'm not sure how librarian-puppet helps if we're either including code
in the same git repo, or don't have network access at any point.
···
On 25/09/13 12:40, Marek Hulan wrote:
> On Monday 16 of September 2013 09:28:27 Dominic Cleal wrote:
>> On 16/09/13 07:10, Marek Hulan wrote:
>>> On Sunday 15 of September 2013 20:44:15 Greg Sutcliffe wrote:
>>>> I'm fine with giving this a go during the 1.4 dev cycle.
>>>
>>> I'd really like to use librarian-puppet for this in future [1]. I tried to
>>> use it for new installer but we should first make sure dependencies are
>>> set correctly in our modules. With this, we could just distribute
>>> Puppetfile with a particular foreman release. And also we wouldn't have
>>> to track all dependencies in foreman-installer repo, just those we want
>>> to install. Their dependencies would be resolved by librarian-puppet.
>>
>> I think the two proposals are orthogonal, but sure, we can consider this
>> too.
>>
>> How do you see package builds work? We'd run librarian-puppet during
>> the package build, or would we supply pristine sources for each of the
>> modules that we'd be using and combine them? I can't see this working
>> at runtime, that's all.
>
> I think we should have the modules code in our git just as a regular code. I
> think we don't have network access during packaging process so we would have
> to supply sources as you suggest. And definitely it should not be used at
> runtime. It's just a tool for version and dependency management so we don't
> need subtree or submodules. The packaging would remain the same I guess.
