Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My temporary PHP fix from 2014 has nearly 20M installs. Today I'm deprecating it

jakeasmith.com

Post reply on HN
Print view View original

31–40 of 88 posts

Re: My temporary PHP fix from 2014 has nearly 20M installs. Today I'm deprecating it

#31

Post by lukeify »

mech422 wrote: post #29
dolmen wrote: post #24

Earlier quoted context omitted.

From the article: > So I had a decision to make. I could dive back into PHP after almost a decade away, hand the package to one of the people who’d offered, or let it keep sitting there. We are in the AI era. As a maintainer of an open source project that I haven't touched for years, I would first start by asking an AI to produce a fix for the issue and check what it proposes. This definitely reduces the mental load…

The down vote was me - I really think calling deprecating a project after a decade+ telling the world 'depending on this project was a bad idea' is tone deaf.

Others would say pragmatic.

Re: My temporary PHP fix from 2014 has nearly 20M installs. Today I'm deprecating it

#32

Post by post-it »

dolmen wrote: post #24
jakeasmith wrote: post #2

Author here, happy to answer any questions. I never imagined a polyfill for http_build_url would gain so much traction. After 12 years, deprecating it feels like the right move, especially given the new options from the community and PHP itself.

From the article: > So I had a decision to make. I could dive back into PHP after almost a decade away, hand the package to one of the people who’d offered, or let it keep sitting there. We are in the AI era. As a maintainer of an open source project that I haven't touched for years, I would first start by asking an AI to produce a fix for the issue and check what it proposes. This definitely reduces the mental load…

Why don't you do it?

Re: My temporary PHP fix from 2014 has nearly 20M installs. Today I'm deprecating it

#33

Post by iso1631 »

mech422 wrote: post #29
dolmen wrote: post #24

Earlier quoted context omitted.

From the article: > So I had a decision to make. I could dive back into PHP after almost a decade away, hand the package to one of the people who’d offered, or let it keep sitting there. We are in the AI era. As a maintainer of an open source project that I haven't touched for years, I would first start by asking an AI to produce a fix for the issue and check what it proposes. This definitely reduces the mental load…

The down vote was me - I really think calling deprecating a project after a decade+ telling the world 'depending on this project was a bad idea' is tone deaf.

I think it shows a complete misunderstanding on what free software is.

Re: My temporary PHP fix from 2014 has nearly 20M installs. Today I'm deprecating it

#34

Post by serial_dev »

dolmen wrote: post #24
jakeasmith wrote: post #2

Author here, happy to answer any questions. I never imagined a polyfill for http_build_url would gain so much traction. After 12 years, deprecating it feels like the right move, especially given the new options from the community and PHP itself.

From the article: > So I had a decision to make. I could dive back into PHP after almost a decade away, hand the package to one of the people who’d offered, or let it keep sitting there. We are in the AI era. As a maintainer of an open source project that I haven't touched for years, I would first start by asking an AI to produce a fix for the issue and check what it proposes. This definitely reduces the mental load…

We are in the AI era, it doesn't change the fact that investing 1 hrs a month (or even a week) into a long-dead project in a language you no longer use is more investment than 0 hours for the rest of your life.

And yes, if your timeline as a dependency enjoyer is "is this project going to be maintained for 15 years" and you still assumed the answer is yes, it's kind of on you adding a dependency.

Re: My temporary PHP fix from 2014 has nearly 20M installs. Today I'm deprecating it

#35

Post by dspillett »

dolmen wrote: post #24
jakeasmith wrote: post #2

Author here, happy to answer any questions. I never imagined a polyfill for http_build_url would gain so much traction. After 12 years, deprecating it feels like the right move, especially given the new options from the community and PHP itself.

From the article: > So I had a decision to make. I could dive back into PHP after almost a decade away, hand the package to one of the people who’d offered, or let it keep sitting there. We are in the AI era. As a maintainer of an open source project that I haven't touched for years, I would first start by asking an AI to produce a fix for the issue and check what it proposes. This definitely reduces the mental load…

Even with AI, the result needs to be reviewed both to make sure it is actually correct in what it intends to do and that it does not have knock-on effects anywhere else. Given the description of the bug I'd think that spinning up the AI and pointing it in the right direction would save no time over just fixing the issue completely by hand.

Fixing the issue could set an expectation in current users of the package that it might get updates going forward, which it obviously won't from this maintainer, potentially reducing any impetus that might exist to move over to something that is a more correct solution these days. Handing over control of the project where it is has risks which are stated in TFA.

So while both fixing and deprecating could have been done, I think the right choice (just mark it as deprecated) has been made. Not fixing the existing bug(s) will not break anything that is using the package any more than it is already broken. If one of the existing issues had potential to be a security issue then I might err more towards fix+deprecate (with big red text included in any announcement of the fix to the effect that this is the last one and future issues won't get resolved upstream).

Re: My temporary PHP fix from 2014 has nearly 20M installs. Today I'm deprecating it

#36

Post by dspillett »

mech422 wrote: post #29
dolmen wrote: post #24

Earlier quoted context omitted.

From the article: > So I had a decision to make. I could dive back into PHP after almost a decade away, hand the package to one of the people who’d offered, or let it keep sitting there. We are in the AI era. As a maintainer of an open source project that I haven't touched for years, I would first start by asking an AI to produce a fix for the issue and check what it proposes. This definitely reduces the mental load…

The down vote was me - I really think calling deprecating a project after a decade+ telling the world 'depending on this project was a bad idea' is tone deaf.

It doesn't say that depending on it was a bad idea, but that depending on it going forward is a bad idea, and they've gone the extra mile and made an announcement including information about what better alternatives are not available.

Would you prefer it just sat there unfixed and unsupported?

Re: My temporary PHP fix from 2014 has nearly 20M installs. Today I'm deprecating it

#37

Post by dspillett »

iso1631 wrote: post #33
mech422 wrote: post #29

Earlier quoted context omitted.

The down vote was me - I really think calling deprecating a project after a decade+ telling the world 'depending on this project was a bad idea' is tone deaf.

I think it shows a complete misunderstanding on what free software is.

Free software is Free (and free software is free, libre software is libre, …, where the free/Free/libre/OS/… distinctions are relevant). That does not guarantee continued maintenance for decades, and to expect such is the sort of entitlement that puts some people off sharing their work and playthings.

Re: My temporary PHP fix from 2014 has nearly 20M installs. Today I'm deprecating it

#39

Post by dspillett »

hdjrudni wrote: post #10
Codefrontier wrote: post #4

Love you kept it alive this long

It hasn't been updated in 11 years. Not sure I'd call that "keeping it alive".

Sometimes not touching something that works is the best way to keep it working!

Re: My temporary PHP fix from 2014 has nearly 20M installs. Today I'm deprecating it

#40

Post by 0x073 »

Timwi wrote: post #30
TimWolla wrote: post #8

Earlier quoted context omitted.

The package is marked as abandoned on Packagist [1] > This package is abandoned and no longer maintained. No replacement package was suggested. Both adding it as a dependency using composer and installing it from a lockfile results in: $ composer require jakeasmith/http_build_url […] Package jakeasmith/http_build_url is abandoned, you should avoid using it. No replacement was suggested. […] $ rm -r vendor/ $ composer…

It would have been nice if a replacement had been suggested.

Replacement is defined in the github repo, in composer you can only define an replacement package, but there is no real replacement, just alternative ways.
Post reply on HN