while the original plan was to switch to Rails 5.0 soon and then begin
5.1 work, it's a major downside that RPMs would be broken for a
potentially longer period, so I closed https://github.com/theforeman/foreman/pull/4867 and like to draw the
attention of interested parties to https://github.com/theforeman/foreman/pull/4836 where all the changes
that are queued up lead to a still 100% green Rails 5.0 test run and
leave 21 test failures with 5.1.
I guess two of iNečas' recently opened PRs will fix some of these.
Besides the missing changes to get green tests one major problem is that
there's no Rails 5 compatible version of turbolinks-classic, so either
Foreman needs to move to turbolinks 5 or a forked turbolinks-classic gem
would be needed, if turbolinks should be kept.
In the meanwhile Rails 5.1 should be packaged for RPM in some way…
···
On Tue, Oct 17, 2017 at 4:32 PM, Michael Moll wrote:
Hi,
while the original plan was to switch to Rails 5.0 soon and then begin
5.1 work, it’s a major downside that RPMs would be broken for a
potentially longer period, so I closed https://github.com/theforeman/foreman/pull/4867 and like to draw the
attention of interested parties to https://github.com/theforeman/foreman/pull/4836 where all the changes
that are queued up lead to a still 100% green Rails 5.0 test run and
leave 21 test failures with 5.1.
I guess two of iNečas’ recently opened PRs will fix some of these.
Besides the missing changes to get green tests one major problem is that
there’s no Rails 5 compatible version of turbolinks-classic, so either
Foreman needs to move to turbolinks 5 or a forked turbolinks-classic gem
would be needed, if turbolinks should be kept.
In the meanwhile Rails 5.1 should be packaged for RPM in some way…
I personally would be okay if we removed turbolinks from foreman entirely.
We want to replace it in the future with a true single page app anyway.
But if others want to put in the effort to maintain it I would support that
effort as well.
Cheers,
Walden
···
On Tue, Oct 17, 2017 at 7:48 PM, Eric D Helms wrote:
while the original plan was to switch to Rails 5.0 soon and then begin
5.1 work, it’s a major downside that RPMs would be broken for a
potentially longer period, so I closed https://github.com/theforeman/foreman/pull/4867 and like to draw the
attention of interested parties to https://github.com/theforeman/foreman/pull/4836 where all the changes
that are queued up lead to a still 100% green Rails 5.0 test run and
leave 21 test failures with 5.1.
I guess two of iNečas’ recently opened PRs will fix some of these.
Besides the missing changes to get green tests one major problem is that
there’s no Rails 5 compatible version of turbolinks-classic, so either
Foreman needs to move to turbolinks 5 or a forked turbolinks-classic gem
would be needed, if turbolinks should be kept.
In the meanwhile Rails 5.1 should be packaged for RPM in some way…
···
On Thu, Oct 19, 2017 at 7:55 PM, Walden Raines wrote:
> I personally would be okay if we removed turbolinks from foreman entirely.
> We want to replace it in the future with a true single page app anyway. But
> if others want to put in the effort to maintain it I would support that
> effort as well.
>
> Cheers,
> Walden
>
> On Tue, Oct 17, 2017 at 7:48 PM, Eric D Helms wrote:
>>
>> Thanks for the update Michael. I just want to point interested parties to
>> the RPM side of the discussions that are on going over in
>> https://groups.google.com/forum/#!topic/foreman-dev/xJyxMx1lXy4
>>
>> On Tue, Oct 17, 2017 at 4:32 PM, Michael Moll wrote:
>>>
>>> Hi,
>>>
>>> while the original plan was to switch to Rails 5.0 soon and then begin
>>> 5.1 work, it's a major downside that RPMs would be broken for a
>>> potentially longer period, so I closed
>>> https://github.com/theforeman/foreman/pull/4867 and like to draw the
>>> attention of interested parties to
>>> https://github.com/theforeman/foreman/pull/4836 where all the changes
>>> that are queued up lead to a still 100% green Rails 5.0 test run and
>>> leave 21 test failures with 5.1.
>>>
>>> I guess two of iNečas' recently opened PRs will fix some of these.
>>>
>>> Besides the missing changes to get green tests one major problem is that
>>> there's no Rails 5 compatible version of turbolinks-classic, so either
>>> Foreman needs to move to turbolinks 5 or a forked turbolinks-classic gem
>>> would be needed, if turbolinks should be kept.
>>>
>>> In the meanwhile Rails 5.1 should be packaged for RPM in some way... :)
>>>
>>> Regards
>>> --
>>> Michael Moll
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "foreman-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to foreman-dev+unsubscribe@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>>
>> --
>> Eric D. Helms
>> Red Hat Engineering
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "foreman-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to foreman-dev+unsubscribe@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
I'm also fine with removing them. I don't think it adds much value
when we're moving towards UI based on React.
T.
···
On Fri, Oct 20, 2017 at 8:17 AM, Ivan Necas wrote:
> Not hard feelings from me to remove turbo-links:)
>
> -- Ivan
>
> On Thu, Oct 19, 2017 at 7:55 PM, Walden Raines wrote:
>> I personally would be okay if we removed turbolinks from foreman entirely.
>> We want to replace it in the future with a true single page app anyway. But
>> if others want to put in the effort to maintain it I would support that
>> effort as well.
>>
>> Cheers,
>> Walden
>>
>> On Tue, Oct 17, 2017 at 7:48 PM, Eric D Helms wrote:
>>>
>>> Thanks for the update Michael. I just want to point interested parties to
>>> the RPM side of the discussions that are on going over in
>>> https://groups.google.com/forum/#!topic/foreman-dev/xJyxMx1lXy4
>>>
>>> On Tue, Oct 17, 2017 at 4:32 PM, Michael Moll wrote:
>>>>
>>>> Hi,
>>>>
>>>> while the original plan was to switch to Rails 5.0 soon and then begin
>>>> 5.1 work, it's a major downside that RPMs would be broken for a
>>>> potentially longer period, so I closed
>>>> https://github.com/theforeman/foreman/pull/4867 and like to draw the
>>>> attention of interested parties to
>>>> https://github.com/theforeman/foreman/pull/4836 where all the changes
>>>> that are queued up lead to a still 100% green Rails 5.0 test run and
>>>> leave 21 test failures with 5.1.
>>>>
>>>> I guess two of iNečas' recently opened PRs will fix some of these.
>>>>
>>>> Besides the missing changes to get green tests one major problem is that
>>>> there's no Rails 5 compatible version of turbolinks-classic, so either
>>>> Foreman needs to move to turbolinks 5 or a forked turbolinks-classic gem
>>>> would be needed, if turbolinks should be kept.
>>>>
>>>> In the meanwhile Rails 5.1 should be packaged for RPM in some way... :)
>>>>
>>>> Regards
>>>> --
>>>> Michael Moll
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google Groups
>>>> "foreman-dev" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send an
>>>> email to foreman-dev+unsubscribe@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>>
>>>
>>> --
>>> Eric D. Helms
>>> Red Hat Engineering
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "foreman-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to foreman-dev+unsubscribe@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "foreman-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to foreman-dev+unsubscribe@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
I'm also fine with removing them. I don't think it adds much value
when we're moving towards UI based on React.
I would be happy if someone compare UI responsiveness before we make the
changes
T.
> Not hard feelings from me to remove turbo-links:)
>
> – Ivan
>
>> I personally would be okay if we removed turbolinks from foreman
entirely.
>> We want to replace it in the future with a true single page app anyway.
But
>> if others want to put in the effort to maintain it I would support that
>> effort as well.
>>
>> Cheers,
>> Walden
>>
>>>
>>> Thanks for the update Michael. I just want to point interested parties
to
>>> the RPM side of the discussions that are on going over in
>>> https://groups.google.com/forum/#!topic/foreman-dev/xJyxMx1lXy4
>>>
>>>>
>>>> Hi,
>>>>
>>>> while the original plan was to switch to Rails 5.0 soon and then begin
>>>> 5.1 work, it's a major downside that RPMs would be broken for a
>>>> potentially longer period, so I closed
>>>> https://github.com/theforeman/foreman/pull/4867 and like to draw the
>>>> attention of interested parties to
>>>> https://github.com/theforeman/foreman/pull/4836 where all the changes
>>>> that are queued up lead to a still 100% green Rails 5.0 test run and
>>>> leave 21 test failures with 5.1.
>>>>
>>>> I guess two of iNečas' recently opened PRs will fix some of these.
>>>>
>>>> Besides the missing changes to get green tests one major problem is
that
>>>> there's no Rails 5 compatible version of turbolinks-classic, so either
>>>> Foreman needs to move to turbolinks 5 or a forked turbolinks-classic
gem
>>>> would be needed, if turbolinks should be kept.
>>>>
>>>> In the meanwhile Rails 5.1 should be packaged for RPM in some way…
>>>>
>>>> Regards
>>>> –
>>>> Michael Moll
>>>>
>>>> –
>>>> You received this message because you are subscribed to the Google
Groups
>>>> "foreman-dev" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
an
>>>> email to foreman-dev+unsubscribe@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>>
>>>
>>> –
>>> Eric D. Helms
>>> Red Hat Engineering
>>>
>>> –
>>> You received this message because you are subscribed to the Google
Groups
>>> "foreman-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
an
>>> email to foreman-dev+unsubscribe@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> –
>> You received this message because you are subscribed to the Google Groups
>> "foreman-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to foreman-dev+unsubscribe@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
> –
> You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
···
On Oct 20, 2017 11:39 AM, "Tomas Strachota" wrote:
On Fri, Oct 20, 2017 at 8:17 AM, Ivan Necas wrote:
> On Thu, Oct 19, 2017 at 7:55 PM, Walden Raines wrote:
>> On Tue, Oct 17, 2017 at 7:48 PM, Eric D Helms wrote:
>>> On Tue, Oct 17, 2017 at 4:32 PM, Michael Moll wrote:
> For more options, visit https://groups.google.com/d/optout.
Circling back to this as we've made some progress on the SCL front.
Updates
* Rails 5 SCL initial builds minus turbolinks exist [1]
* Turobolinks 2.4.5 is being released that will have Rails 5 compatability
* Work is progressing to test rebuild Foreman stack against SCL, this will
be followed up runtime tests
Would someone with more knowledge on the code side of the Rails 5 mind
sending along an update of the path we see for getting to 5.1?
···
On Fri, Oct 20, 2017 at 12:20 PM, Ohad Levy <ohadlevy@gmail.com> wrote:
On Oct 20, 2017 11:39 AM, "Tomas Strachota" <tstracho@redhat.com> wrote:
I'm also fine with removing them. I don't think it adds much value
when we're moving towards UI based on React.
I would be happy if someone compare UI responsiveness before we make the
changes
T.
On Fri, Oct 20, 2017 at 8:17 AM, Ivan Necas <inecas@redhat.com> wrote:
Not hard feelings from me to remove turbo-links:)
-- Ivan
On Thu, Oct 19, 2017 at 7:55 PM, Walden Raines <wraines@redhat.com> > wrote:
I personally would be okay if we removed turbolinks from foreman
entirely.
We want to replace it in the future with a true single page app
anyway. But
if others want to put in the effort to maintain it I would support that
effort as well.
Cheers,
Walden
On Tue, Oct 17, 2017 at 7:48 PM, Eric D Helms <ericdhelms@gmail.com> > wrote:
On Tue, Oct 17, 2017 at 4:32 PM, Michael Moll <kvedulv@kvedulv.de> > wrote:
Hi,
while the original plan was to switch to Rails 5.0 soon and then begin
5.1 work, it's a major downside that RPMs would be broken for a
potentially longer period, so I closed
https://github.com/theforeman/foreman/pull/4867 and like to draw the
attention of interested parties to
https://github.com/theforeman/foreman/pull/4836 where all the changes
that are queued up lead to a still 100% green Rails 5.0 test run and
leave 21 test failures with 5.1.
I guess two of iNečas' recently opened PRs will fix some of these.
Besides the missing changes to get green tests one major problem is
that
there's no Rails 5 compatible version of turbolinks-classic, so either
Foreman needs to move to turbolinks 5 or a forked turbolinks-classic
gem
would be needed, if turbolinks should be kept.
In the meanwhile Rails 5.1 should be packaged for RPM in some way...
:)
Regards
--
Michael Moll
--
You received this message because you are subscribed to the Google
Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Eric D. Helms
Red Hat Engineering
--
You received this message because you are subscribed to the Google
Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
* Rails 5 SCL initial builds minus turbolinks exist [1]
* Turobolinks 2.4.5 is being released that will have Rails 5 compatability
* Work is progressing to test rebuild Foreman stack against SCL, this will
be followed up runtime tests
Would someone with more knowledge on the code side of the Rails 5 mind
sending along an update of the path we see for getting to 5.1?
Once there are gem releases out, I'd open PRs to raise the lower version
boundary of these in core and after these got in, I'd ask
https://github.com/theforeman/foreman/pull/4867 to get merged (BTW, Eric, please see the comment at the bottom).
After that one got merged, core is using Rails 5.1 (and probably not
even Rails 5.0 compatible) and the RPM work can start. DEBs should just
work fine without modifications.
Plugin authors should check if anything is missing for Rails 5.1 and
update, if needed.
After that, the remaining deprecation notices with Rails 5.1 should get
fixed and once this is done, Rails 5.2 is probably already released.
Regards
···
On Thu, Nov 30, 2017 at 02:20:09PM -0500, Eric D Helms wrote:
--
Michael Moll
Thanks for the update Michael! In working on test builds, something I
noticed was that we currently have fog 1.41 which is locked to json < 2.
However, Ruby 2.4 provides json 2+. Fog 1.42 appears to require json 2+.
Is this a dependency that we can update alongside the Rails update?
···
On Thu, Nov 30, 2017 at 5:52 PM, Michael Moll <kvedulv@kvedulv.de> wrote:
Hi,
On Thu, Nov 30, 2017 at 02:20:09PM -0500, Eric D Helms wrote:
* Rails 5 SCL initial builds minus turbolinks exist [1]
* Turobolinks 2.4.5 is being released that will have Rails 5
compatability
* Work is progressing to test rebuild Foreman stack against SCL, this
will
be followed up runtime tests
Would someone with more knowledge on the code side of the Rails 5 mind
sending along an update of the path we see for getting to 5.1?
Once there are gem releases out, I'd open PRs to raise the lower version
boundary of these in core and after these got in, I'd ask
https://github.com/theforeman/foreman/pull/4867 to get merged (BTW, Eric, please see the comment at the bottom).
After that one got merged, core is using Rails 5.1 (and probably not
even Rails 5.0 compatible) and the RPM work can start. DEBs should just
work fine without modifications.
Plugin authors should check if anything is missing for Rails 5.1 and
update, if needed.
After that, the remaining deprecation notices with Rails 5.1 should get
fixed and once this is done, Rails 5.2 is probably already released.
Regards
--
Michael Moll
--
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
···
On Thu, Nov 30, 2017 at 08:06:53PM -0500, Eric D Helms wrote:
Thanks for the update Michael! In working on test builds, something I
noticed was that we currently have fog 1.41 which is locked to json < 2.
However, Ruby 2.4 provides json 2+. Fog 1.42 appears to require json 2+.
Is this a dependency that we can update alongside the Rails update?
Thanks for the update Michael! In working on test builds, something I
noticed was that we currently have fog 1.41 which is locked to json < 2.
However, Ruby 2.4 provides json 2+. Fog 1.42 appears to require json 2+.
Is this a dependency that we can update alongside the Rails update?
Good find! I know this will likely break nightlies on the RPM side given
JSON is only at 2+ in Ruby 2.4. However, based on your previous email it
sounds like we are going to have to bite the bullet on some length of time
where RPMs are broken? The question then is how long do we allow that
period to be based upon how much time we give plugins to switch to Rails 5?
···
On Thu, Nov 30, 2017 at 8:16 PM, Michael Moll <kvedulv@kvedulv.de> wrote:
On Thu, Nov 30, 2017 at 08:06:53PM -0500, Eric D Helms wrote:
Regards
--
Michael Moll
--
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
···
On Thu, Nov 30, 2017 at 08:47:12PM -0500, Eric D Helms wrote:
Good find! I know this will likely break nightlies on the RPM side given
JSON is only at 2+ in Ruby 2.4. However, based on your previous email it
sounds like we are going to have to bite the bullet on some length of time
where RPMs are broken? The question then is how long do we allow that
period to be based upon how much time we give plugins to switch to Rails 5?
At the end of the day plugin development is independent from core. Today
all the major plugins are compatible with Rails 4.2 and 5.0. Initially I
thought of one week having core using 5.0, but even now plugin authors
can start working on opening PRs aginst plugins that will fix all the
remaining 5.0 deprecations (breaking 4.2).
* Rails 5 SCL initial builds minus turbolinks exist [1]
* Turobolinks 2.4.5 is being released that will have Rails 5
compatability
* Work is progressing to test rebuild Foreman stack against SCL, this
will
be followed up runtime tests
Would someone with more knowledge on the code side of the Rails 5 mind
sending along an update of the path we see for getting to 5.1?
Once there are gem releases out, I'd open PRs to raise the lower version
boundary of these in core and after these got in, I'd ask
to get merged (BTW, Eric, please see the comment at the bottom).
At that state, core would be using Rails 5.0 only and I'd open one PR
including the 5.0 only parts of
After that one got merged, core would be using Rails 5.0 and be
incompatible with Rails 4.2.
Plugin authors should start updating their plugins to Rails 5.0
standards at that point.
Then I'd open a PR with the switch from Rails 5.0 to 5.1 and
After that one got merged, core is using Rails 5.1 (and probably not
even Rails 5.0 compatible) and the RPM work can start. DEBs should just
work fine without modifications.
Plugin authors should check if anything is missing for Rails 5.1 and
update, if needed.
After that, the remaining deprecation notices with Rails 5.1 should get
fixed and once this is done, Rails 5.2 is probably already released.
Generally speaking, now that we've done the up front work to get the start
of an SCL built, ran basic tests I am OK unblocking migrating core to 5.0
based on the plan above. We'll have a week or three of brokenness but if
we've planned on that and are communicating status routinely then I think
that is the best approach possible to move the code base and fix packaging.
Eric
···
On Thu, Nov 30, 2017 at 5:52 PM, Michael Moll <kvedulv@kvedulv.de> wrote:
On Thu, Nov 30, 2017 at 02:20:09PM -0500, Eric D Helms wrote:
Regards
--
Michael Moll
--
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
* Rails 5 SCL initial builds minus turbolinks exist [1]
* Turobolinks 2.4.5 is being released that will have Rails 5
compatability
* Work is progressing to test rebuild Foreman stack against SCL, this
will
be followed up runtime tests
Would someone with more knowledge on the code side of the Rails 5 mind
sending along an update of the path we see for getting to 5.1?
Once there are gem releases out, I'd open PRs to raise the lower version
boundary of these in core and after these got in, I'd ask
to get merged (BTW, Eric, please see the comment at the bottom).
At that state, core would be using Rails 5.0 only and I'd open one PR
including the 5.0 only parts of
After that one got merged, core would be using Rails 5.0 and be
incompatible with Rails 4.2.
Plugin authors should start updating their plugins to Rails 5.0
standards at that point.
Then I'd open a PR with the switch from Rails 5.0 to 5.1 and
After that one got merged, core is using Rails 5.1 (and probably not
even Rails 5.0 compatible) and the RPM work can start. DEBs should just
work fine without modifications.
Plugin authors should check if anything is missing for Rails 5.1 and
update, if needed.
After that, the remaining deprecation notices with Rails 5.1 should get
fixed and once this is done, Rails 5.2 is probably already released.
Generally speaking, now that we've done the up front work to get the start
of an SCL built, ran basic tests I am OK unblocking migrating core to 5.0
based on the plan above. We'll have a week or three of brokenness but if
we've planned on that and are communicating status routinely then I think
that is the best approach possible to move the code base and fix packaging.
even 5.1) now so we can start seeing the issues.
thanks!
Ohad
···
On Mon, Dec 4, 2017 at 9:57 PM, Eric D Helms <ericdhelms@gmail.com> wrote:
On Thu, Nov 30, 2017 at 5:52 PM, Michael Moll <kvedulv@kvedulv.de> wrote:
On Thu, Nov 30, 2017 at 02:20:09PM -0500, Eric D Helms wrote:
Eric
Regards
--
Michael Moll
--
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Eric D. Helms
Red Hat Engineering
--
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Nothing happened here, yet. So I propose to go forward now as outlined
below and if we're on 5.1 and oauth still didn't move, we fork that gem.
Once there are gem releases out, I'd open PRs to raise the lower version
boundary of these in core and after these got in, I'd ask
to get merged (BTW, Eric, please see the comment at the bottom).
At that state, core would be using Rails 5.0 only and I'd open one PR
including the 5.0 only parts of
After that one got merged, core would be using Rails 5.0 and be
incompatible with Rails 4.2.
Plugin authors should start updating their plugins to Rails 5.0
standards at that point.
Then I'd open a PR with the switch from Rails 5.0 to 5.1 and
After that one got merged, core is using Rails 5.1 (and probably not
even Rails 5.0 compatible) and the RPM work can start. DEBs should just
work fine without modifications.
Plugin authors should check if anything is missing for Rails 5.1 and
update, if needed.
After that, the remaining deprecation notices with Rails 5.1 should get
fixed and once this is done, Rails 5.2 is probably already released.
Regards
···
On Thu, Nov 30, 2017 at 11:52:24PM +0100, Michael Moll wrote:
--
Michael Moll
Once there are gem releases out, I’d open PRs to raise the lower version
boundary of these in core and after these got in, I’d ask https://github.com/theforeman/foreman/pull/4867
to get merged (BTW, Eric, please see the comment at the bottom).
After that one got merged, core is using Rails 5.1 (and probably not
even Rails 5.0 compatible) and the RPM work can start. DEBs should just
work fine without modifications.
Plugin authors should check if anything is missing for Rails 5.1 and
update, if needed.
The final step to Rails 5.1 got just merged.
After that, the remaining deprecation notices with Rails 5.1 should get
fixed and once this is done, Rails 5.2 is probably already released.
The remaining deprecation warnings with 5.1 can be found in
config/as_deprecation_whitelist.yaml
After that one got merged, core is using Rails 5.1 (and probably not
even Rails 5.0 compatible) and the RPM work can start. DEBs should just
work fine without modifications.
Plugin authors should check if anything is missing for Rails 5.1 and
update, if needed.
The final step to Rails 5.1 got just merged.
After that, the remaining deprecation notices with Rails 5.1 should get
fixed and once this is done, Rails 5.2 is probably already released.
The remaining deprecation warnings with 5.1 can be found in
config/as_deprecation_whitelist.yaml
Thank you Michael for leading the effort! Much appreciated
Ohad
Regards
···
On Dec 22, 2017 8:12 PM, "Michael Moll" <kvedulv@kvedulv.de> wrote:
--
Michael Moll
