For 1.2, I intend to release foreman-installer as part of the RC process
so we can test everything together. As a number of people have
requested, we're also going to release the modules onto Puppet Forge
under the account "theforeman".
I've started off by adding Modulefiles and bits to all the modules (if
somebody could review and merge soon, that'd be appreciated for RC1):
I'm thinking though that the 1.2-stable branch process is a bit of an
overhead for the installer, particularly as we only have one master
branch for the submodules.
Unless anybody objects, I plan to do use this branching strategy:
update default repo to be "RC" instead of "stable" in foreman/proxy
modules
update all module version numbers for the upcoming release, including
each RC
update submodules in foreman-installer develop to the latest
build foreman-installer packages and modules from develop
Actually I think that for foreman-installer it makes sense to drop
develop, move all development to master and have release branches to
match foreman itself. I'm not sure if it makes sense to do the same for
each submodule since I think we can keep them API-compatible. If we
can't, then fork a 1.2 branch.
···
On Mon, May 20, 2013 at 12:19:42PM +0100, Dominic Cleal wrote:
> I'm thinking though that the 1.2-stable branch process is a bit of an
> overhead for the installer, particularly as we only have one master
> branch for the submodules.
I'd agree, but will leave completely reworking it to post-1.2 as we
should look at it with foreman and smart-proxy repos too for consistency.
I'll use a 1.2-stable branch for the installer as well then as it gets
us nearer to this idea.
···
On 20/05/13 13:02, Ewoud Kohl van Wijngaarden wrote:
> On Mon, May 20, 2013 at 12:19:42PM +0100, Dominic Cleal wrote:
>> I'm thinking though that the 1.2-stable branch process is a bit of an
>> overhead for the installer, particularly as we only have one master
>> branch for the submodules.
>
> Actually I think that for foreman-installer it makes sense to drop
> develop, move all development to master and have release branches to
> match foreman itself. I'm not sure if it makes sense to do the same for
> each submodule since I think we can keep them API-compatible. If we
> can't, then fork a 1.2 branch.