New release with PHP 8 support?

[dzuelke]

Hi @Danack and others,

PHP 8.0.0 is getting really close and it looks like this extension supports it already.

All that's missing is a Git tag, and a release to PECL :)

Would be super if that could be done anytime soon so that e.g. PaaSes have a stable release version to provide to customers.

Thanks!

[kowalski7cc]

duplicate of #331

[dzuelke]

Sort of; I am specifically asking to just cut a release from what already works ;)

[lzsiga]

Couldn't compile imagick with PHP-8 either: the interface of extensions has been changed again.

[stecklars]

Considering that PHP 8.0 is about to be released, is there an update? That would be very helpful. Thanks :)

[centminmod]

yes please :)

[vladislavtkachenko]

@Danack We are looking forward to the release of Imagic, before tomorrow's php 8 release

[waja]

For all those brave ppl asking for a PHP8 compatible release: How about providing fixes and/or pull requests? Just complaining that something doesn't work which is provided free as beer does not work. OpenSource lives from contribution!

[vladislavtkachenko]

It's probably much easier for people who are familiar with the code and have developed it to make improvements than for those who are just reaping the benefits

[Danack]

waja wrote:

OpenSource lives from contribution!

Hmm. Actually I don't think it does. It's much more of a 'people need to be able to afford food and housing' problem than needing more contributors.

vladislavtkachenko wrote:

We are looking forward to the release of Imagic, before tomorrow's php 8 release

This maybe a cultural difference, but to me this is a aggravatingly passive aggressive tone to use. You are setting your expectation that you expect someone to do work for free on your preferred timeline.

[vladislavtkachenko]

Sorry if that sounded rude. I meant that the community uses the package and hopes to continue using it, but not everyone can make changes to fix some errors. And we hope for you.
Thank you for your work, Danack

[Danack]

dzuelke wrote:

PaaSes have a stable release version to provide to customers.

David, I believe you work for a wholly owned subsidiary of a large multinational company that has approximately $17 billion in annual revenue.

I fully understand that having all the libraries that your customers need to upgrade to PHP 8 available on the day that PHP 8 launches would be of benefit to them, and also to your company.

It won't make any difference to the timeline of shipping a version that supports PHP 8, but if having OpenSource projects be maintained is of value to you, please look at sponsoring the work I do: https://github.com/sponsors/Danack Or you can contact me via email if for any reasons going through github sponsors is not desirable.

I'll write more elsewhere but to summarize; I do not enjoy supporting this library and I do not use this library. Which makes working on it be a thing that I wonder why I do.

dzuelke wrote:

I am specifically asking to just cut a release from what already works ;)

For the record, 'just' is a four letter word. My problem with it is that it is not a productive conversational technique. In this case it assumes that something is going to be simple, which means that the person who knows why something might be difficult has to push back, before the conversation even begins.

In this case, asking 'what else needs to be done for the release?' would have been more productive, and the answer would have been:

• Merge the remaining PRs that Remi has provided.
• Review parameter names and update them to be saner. Many of the param names were chosen....poorly. This has not been that much of an issue up until now, but with named params support in PHP 8, they should probably need to be better chosen.
• Figure out why a very old test has begun to fail and determine if it's worth fixing.
• Check for anything else that needs to be done.
• Write the release notes and prep the release.

[mkoppanen]

Interesting to see Heroku open source strategy in action:

1. Open an issue
2. ???
3. Profit!

[dzuelke]

Alright folks. Slow down.

First of all, apologies for the use of "just". I indeed meant it as "limited in scope to releasing the current state", not "finally fixing all the outstanding invisible issues".

The reasoning being that tagging a first release (there always are betas/RCs for this extension, which is great for this purpose) makes it easier for people to test it - mainly beacuse a pecl install becomes possible, so the barrier to building from source for many users is drastically lower, and it has a particular version attached to it, which makes it a lot easier for any services/platforms/tools that provide the extension (since it has a known number and stability, e.g. for Composer dependency usage), which all helps with broader testing.

The sole recent open issue that related to PHP 8 support, #331, said "should work now", and there were no obvious other outstanding issues reported on the repo, or e.g. issues that tracked the failing builds you're now mentioning, @Danack.

The most up to date information I had at the time when I opened this issue was that "it's fixed in master", with no indication that there were outstanding todos.

Todos I would of course be happy to dedicate personal and work time to help with where I could.

For example, you now created issue #362, and that's something I can probably indeed look at, as I was just recently attempting to track changes to resource limit handling in ImageMagick (AFAICT they're side effects of bugfixes in recent versions).

But if this sort of stuff isn't tracked anywhere and visible, I can't know about it. Nor can anybody else.

Which of course does not absolve me from first asking "what else needs to be done for this release?", as @Danack has rightfully reminded me!

Would it maybe be possible to create a milestone for the new release and assigning any outstanding issues and PRs to that milestone so that it's clear for me and others how to contribute to the effort?

Thanks!

[dzuelke]

@mkoppanen I'm sorry we haven't been able to show the same level of "giving back" to the PHP ecosystem so far as we have for, say, e.g. Ruby, whose creator (and others) we hired in 2011 to work on the language full-time.

As you can probably imagine, it's the very fact that we are now part of such a large organization that can sometimes make these things difficult.

That being said, like many other parts of our systems, the so-called buildpacks we create for language support on the Heroku platfporm are all open source, and used widely by not only competing free or commercial platforms, but also by open source alternatives like Dokku or Herokuish, which use our buildpacks and even the binaries we provide to let you run a self-hosted Heroku-like PaaS.

Meaning you can git push to your own infrastructure, and it'll use the ext-imagick builds we provide.

As you can probably imagine, these users will be asking for ImageMagick support for PHP 8 just as quickly as our (free or paying) customers, and they all will benefit from an eventual release.

Just in case that helps with the "???" portion of your comment.