Skip to Content.
Sympa Menu

comanage-dev - Re: [comanage-dev] CakePHP 2.x Sunset Finally Sort of Announced

Subject: COmanage Developers List

List archive

Re: [comanage-dev] CakePHP 2.x Sunset Finally Sort of Announced


Chronological Thread 
  • From: Heather Flanagan <>
  • To: Benn Oshrin <>,
  • Cc: Steve Zoppi <>
  • Subject: Re: [comanage-dev] CakePHP 2.x Sunset Finally Sort of Announced
  • Date: Sat, 24 Jun 2017 07:09:19 -0700
  • Ironport-phdr: 9a23:b4cWVB39L6Gzs/pssmDT+DRfVm0co7zxezQtwd8ZsegULPad9pjvdHbS+e9qxAeQG96Eu7QZ06L/iOPJZy8p2d65qncMcZhBBVcuqP49uEgeOvODElDxN/XwbiY3T4xoXV5h+GynYwAOQJ6tL3WbmHC57CYTFxPjLkI1Y72tQs+Bx/iwgsq//ZubRB5Inju7Ked4IROwqi3QsNUbm41vNvx3xxfU9D8AcONTzGVhKl/Wkxvizsa24JN59SlM4bQs+9MTf7/9evEYQLVEDDk8e04x7cviuhDFBV+P4nUYW2MfnRNOKwfA5RD+GJz2t32p5aJGxCCGMJiuHvgPUjO44vIuEUewhQ==

Topic for the TechEx f2f?

-Heather

On 6/23/17 5:24 PM, Benn Oshrin wrote:
> In short, security fixes will be provided for 18 months after CakePHP
> 4.0.0 is announced, which is probably going to happen towards the middle
> of next year. That means we need to be on the new framework by mid to
> late 2019.
>
> https://bakery.cakephp.org/2017/06/23/upcoming-cakephp-roadmap.html
>
> While this is a tentative timeline, it's important that we start
> planning around it. We should start figuring out how to resource and
> schedule a framework migration project, probably in 1H18.
>
> During the migration, which I'm ballparking as at least a 3 month
> project, we should plan on no other new feature development, but we
> should look at using this as an opportunity to do things like overhaul
> our testing processes and clean out some longstanding bugs/design flaws.
>
> Note also CakePHP 4.0.0 will require PHP 7.1.0 or later, which has
> impact for our deployers. That said, by 2018 everything prior to PHP 5.6
> is EOL, while 5.6 and 7.0 are in security fix only mode.
>
> I'd also like to consider doing some other work with the new framework
> before the migration. COmanage Directory or a production quality rewrite
> of the Postgres ID Match engine would both be good candidates, if we can
> figure out how to resource one or both...
>
> Thanks,
>
> -Benn-
>




Archive powered by MHonArc 2.6.19.

Top of Page