Re: [PHP-DEV] GD vs Imagick

This is only part of a thread. view whole thread
  100331
August 31, 2017 01:30 kris.craig@gmail.com (Kris Craig)
2. Releasing Imagick with PHP means that the release cycles would need

to be sync'ed. This has proven to be inconvenient in the past when an
extension has wanted to change the api, but was forced to wait due to
needed to wait for the next minor/major version of PHP.


Why would they need to be synced?  When PHP releases a new version, can't
we just bundle the latest Imagick build and plug into that?

Sure, having them in sync would yield certain benefits, but none of them
appear to be deal-breakers to me.  Or am I just missing something?

--Kris
  100464
September 8, 2017 09:34 rasmus@mindplay.dk (Rasmus Schultz)
Yeah, I keep thinking about this.

I'm not sure there's a really good reason why PHP shouldn't come with
best-in-class image support, if it's available - which it sounds like it
is; libvips looks more modern, lower memory and CPU overhead, better
overall really, and appears to be stable and up-to-date?

Yeah, it has dependencies. Doesn't everything? Does it matter, as long as
they're bundled?


On Thu, Aug 31, 2017 at 3:30 AM, Kris Craig craig@gmail.com> wrote:

> 2. Releasing Imagick with PHP means that the release cycles would need > > to be sync'ed. This has proven to be inconvenient in the past when an > extension has wanted to change the api, but was forced to wait due to > needed to wait for the next minor/major version of PHP. > > > Why would they need to be synced? When PHP releases a new version, can't > we just bundle the latest Imagick build and plug into that? > > Sure, having them in sync would yield certain benefits, but none of them > appear to be deal-breakers to me. Or am I just missing something? > > --Kris > >
  100930
October 24, 2017 11:02 danack@basereality.com (Dan Ackroyd)
On 31 August 2017 at 02:30, Kris Craig craig@gmail.com> wrote:

> Why would they need to be synced?
Currently Imagick can have a single branch. Commits to that branch are made and then for the next release, we can determine if it needs to be a major minor or patch release based on the changes. People are then free to upgrade to the next version of Imagick at their own leisure. Or not if they don't feel like it. If it was shipped as part of PHP it would need to have: One branch for each version of PHP supported. Which for now is 5.6, 7.0, 7.1, 7.2 and 7.next Each commit to Imagick would need to be evaluated for whether it should be brought to those branches. Additionally we would probably need to have an additional branch for BC breaking stuff to do in, to await PHP 8. Not only would this be a maintenance burden for the developers, it would also be an arse for end-users. "Oh, you want to upgrade to PHP 7.3? Then you also need to upgrade Imagick, even though you'd prefer to keep to the current version, as it works fine for you." "Oh, you want the new version of Imagick that has a BC breaking change in it? Well sorry, you'll need to wait for PHP 8 for that." cheers Dan