Rather than keep it on my fork, I'd like to propose a new branch that'll
be running 4.2 until it's ready to merge. Specifically:
I'll send the last three develop-compatible changes into Foreman's
develop branch.
I'll create a "develop/rails42" or "rails42" branch from develop on
our main "theforeman" repo, and enable PR tests on Jenkins for it.
I'll propose my 4.2 changes against this as a regular PR and it can
be reviewed as usual and merged to the 4.2 branch.
I'll set up a Jenkins job to periodically run tests on it, merged
with develop so we know it continues to work.
Further 4.2-only changes get PRed to that branch, probably just updates
to the version of Rails. If the job fails due to merge conflicts then a
manual merge of develop can be PRed to the 4.2 branch. If it fails due
to something else then a PR can be raised against develop or 4.2 as
appropriate.
Is that OK with the other maintainers?
Plugin authors can test against this branch, and if somebody from the
Katello project could work on making it compatible too
(http://ci.theforeman.org/job/test_katello_core/17846/) then the 4.2
branch can be merged straight into develop or the patch re-proposed
whenever it's all ready. There's a some RPM packaging work to do as
well, but much less than the update to ror41 (see my previous e-mail).
There have only been a few incompatible changes in 4.2 in my experience,
and it's mostly around monkey patching, relying on Rails internals and
app-wide initialisation, so I don't expect plugins to have much work to
do. There have been plenty of new deprecations which are simply log
noise in 4.2, but won't get removed until 5.0. I'll write up a wiki
page with more guidance.
···
On 03/04, Dominic Cleal wrote:
> 1. I'll send the last three develop-compatible changes into Foreman's
> develop branch.
> 2. I'll create a "develop/rails42" or "rails42" branch from develop on
> our main "theforeman" repo, and enable PR tests on Jenkins for it.
> 3. I'll propose my 4.2 changes against this as a regular PR and it can
> be reviewed as usual and merged to the 4.2 branch.
> 4. I'll set up a Jenkins job to periodically run tests on it, merged
> with develop so we know it continues to work.
> .....
> Is that OK with the other maintainers?
--
Daniel Lobato Garcia
Rather than keep it on my fork, I’d like to propose a new branch that’ll
be running 4.2 until it’s ready to merge. Specifically:
I’ll send the last three develop-compatible changes into Foreman’s
develop branch.
I’ll create a “develop/rails42” or “rails42” branch from develop on
our main “theforeman” repo, and enable PR tests on Jenkins for it.
I’ll propose my 4.2 changes against this as a regular PR and it can
be reviewed as usual and merged to the 4.2 branch.
I’ll set up a Jenkins job to periodically run tests on it, merged
with develop so we know it continues to work.
Further 4.2-only changes get PRed to that branch, probably just updates
to the version of Rails. If the job fails due to merge conflicts then a
manual merge of develop can be PRed to the 4.2 branch. If it fails due
to something else then a PR can be raised against develop or 4.2 as
appropriate.
Is that OK with the other maintainers?
Plugin authors can test against this branch, and if somebody from the
Katello project could work on making it compatible too
(http://ci.theforeman.org/job/test_katello_core/17846/) then the 4.2
branch can be merged straight into develop or the patch re-proposed
whenever it’s all ready. There’s a some RPM packaging work to do as
well, but much less than the update to ror41 (see my previous e-mail).
There have only been a few incompatible changes in 4.2 in my experience,
and it’s mostly around monkey patching, relying on Rails internals and
app-wide initialisation, so I don’t expect plugins to have much work to
do. There have been plenty of new deprecations which are simply log
noise in 4.2, but won’t get removed until 5.0. I’ll write up a wiki
page with more guidance.
Please use this for testing, though do merge develop into your local
copy first so everything's up to date. If there are ever conflicts, we
can re-merge develop into that branch.
> 4. I'll set up a Jenkins job to periodically run tests on it, merged
> with develop so we know it continues to work.
> Plugin authors can test against this branch, and if somebody from the
> Katello project could work on making it compatible too
> (http://ci.theforeman.org/job/test_katello_core/17846/) then the 4.2
> branch can be merged straight into develop or the patch re-proposed
> whenever it's all ready.
> There have only been a few incompatible changes in 4.2 in my experience,
> and it's mostly around monkey patching, relying on Rails internals and
> app-wide initialisation, so I don't expect plugins to have much work to
> do. There have been plenty of new deprecations which are simply log
> noise in 4.2, but won't get removed until 5.0. I'll write up a wiki
> page with more guidance.
>> 1. I'll send the last three develop-compatible changes into Foreman's
>> develop branch.
Last two now in PRs, #3289 and #3290.
>> 2. I'll create a "develop/rails42" or "rails42" branch from develop on
>> our main "theforeman" repo, and enable PR tests on Jenkins for it.
Done.
>> 3. I'll propose my 4.2 changes against this as a regular PR and it can
>> be reviewed as usual and merged to the 4.2 branch.
>> 4. I'll set up a Jenkins job to periodically run tests on it, merged
>> with develop so we know it continues to work.
>> …
>> Is that OK with the other maintainers?
> Sounds great, periodically = nightly? Thanks!
Yep, I've set it to run nightly at around 5-6am UTC.
···
On 07/03/16 10:46, Daniel Lobato Garcia wrote:
> On 03/04, Dominic Cleal wrote:
This has been running for a month now with no further issues, and it's
time to merge rails42 to develop. I plan to do this within a couple of
weeks.
Rails 42 - Foreman contains
info for plugin maintainers to check and test compatibility. This
includes Katello, its Redmine ticket appears unfixed.
Any plugin with DB migrations should be checking the wiki page and at
least updating string limits in existing migrations.
···
On 11/03/16 12:48, Dominic Cleal wrote:
> On 04/03/16 13:17, Dominic Cleal wrote:
>> 3. I'll propose my 4.2 changes against this as a regular PR and it can
>> be reviewed as usual and merged to the 4.2 branch.
>
> This is now merged, so
> https://github.com/theforeman/foreman/commits/rails42 contains a working
> Rails 4.2 version of Foreman.
>
> Please use this for testing, though do merge develop into your local
> copy first so everything's up to date. If there are ever conflicts, we
> can re-merge develop into that branch.
>
>> 4. I'll set up a Jenkins job to periodically run tests on it, merged
>> with develop so we know it continues to work.
>
> This runs at http://ci.theforeman.org/job/test_develop_rails42/.
> >> 2. I'll create a "develop/rails42" or "rails42" branch from develop on
> >> our main "theforeman" repo, and enable PR tests on Jenkins for it.
>
> Done.
>>> 3. I'll propose my 4.2 changes against this as a regular PR and it can
>>> be reviewed as usual and merged to the 4.2 branch.
>>
>> This is now merged, so
>> https://github.com/theforeman/foreman/commits/rails42 contains a working
>> Rails 4.2 version of Foreman.
>>
>> Please use this for testing, though do merge develop into your local
>> copy first so everything's up to date. If there are ever conflicts, we
>> can re-merge develop into that branch.
>>
>>> 4. I'll set up a Jenkins job to periodically run tests on it, merged
>>> with develop so we know it continues to work.
>>
>> This runs at http://ci.theforeman.org/job/test_develop_rails42/.
>
> This has been running for a month now with no further issues, and it's
> time to merge rails42 to develop. I plan to do this within a couple of
> weeks.
I'm going to merge this now, which has some implications for nightly RPM
packages.
Nightly builds will be disabled temporarily until I've done a rebuild
against the newer software collections, like last time. This should be a
lot quicker as fewer packages will be rebuilt, so I hope to have the
builds done by the end of the week or so, then I'll re-enable tests and
push to yum.theforeman.org.
Katello will also need to rebuild anything containing dependencies on
scl_prefix_ror once that's done.
Nightly Debian packages should be without delay, subject to any new bugs
that package tests find.
All plugins should be reading:
> Rails 42 - Foreman contains
> info for plugin maintainers to check and test compatibility.
>
> Any plugin with DB migrations should be checking the wiki page and at
> least updating string limits in existing migrations.
Cheers,
···
On 11/04/16 12:02, Dominic Cleal wrote:
> On 11/03/16 12:48, Dominic Cleal wrote:
>> On 04/03/16 13:17, Dominic Cleal wrote:
>>>> 2. I'll create a "develop/rails42" or "rails42" branch from develop on
>>>> our main "theforeman" repo, and enable PR tests on Jenkins for it.
>>
>> Done.
>
> Something is wrong, I don't see "Update Rails to 4.2" commit in that
> branch: https://github.com/theforeman/foreman/commits/rails42
That branch is just a copy of develop at the moment so I could start the
process, but see:
···
On 10/03/16 09:27, Lukas Zapletal wrote:
On 04/03/16 13:17, Dominic Cleal wrote:
I’ll propose my 4.2 changes against this as a regular PR and it can
be reviewed as usual and merged to the 4.2 branch.
> I'm going to merge this [rails42 branch] now, which has some implications
> for nightly RPM packages.
I merged Rails 4.2 into develop with commit 85a9714, and I've deleted
the old rails42 branch.
> Nightly builds will be disabled temporarily until I've done a rebuild
> against the newer software collections, like last time. This should be a
> lot quicker as fewer packages will be rebuilt, so I hope to have the
> builds done by the end of the week or so, then I'll re-enable tests and
> push to yum.theforeman.org.
The nightly core and plugin RPMs are entirely rebuilt now, and will be
pushed tomorrow morning (~9am UTC) if tests are all OK.
The Fedora builds are disabled as well for now because of the dependency
on 4.2, which is in Fedora 24. It's due to enter beta in a couple of
weeks, so I'll try and re-enable builds at that point.
> Katello will also need to rebuild anything containing dependencies on
> scl_prefix_ror once that's done.
Also ensure the centos-sclo-sclo-rhel-6/7 external repos are attached to
any build tags.
> Nightly Debian packages should be without delay, subject to any new bugs
> that package tests find.
