Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore(deps): update dependency amphp/amp to v3 #1262

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented Dec 18, 2022

Mend Renovate

This PR contains the following updates:

Package Type Update Change
amphp/amp (source) require-dev major ^2.6 -> ^3.0

Release Notes

amphp/amp

v3.0.0: 3.0.0

Compare Source

Event Loop

Amp no longer ships its own event loop. It's now based on Revolt. Revolt\EventLoop is quite similar to Amp's previous Amp\Loop. A very important difference is using float $seconds instead of int $milliseconds for timers though!

Promises

Future is a replacement for the previous Promise.
There's no need for callbacks or yield anymore!
Its await() method is based on fibers and replaces generator based coroutines / Amp\Promise\wait().

  • Renamed Amp\Deferred to Amp\DeferredFuture.
  • Removed Amp\Promise\wait(): Use Amp\Future::await() instead, which can be called in any (nested) context unlike before.
  • Removed Amp\call(): Remove the passed closure boilerplate and all yield keywords, interruption is handled via fibers now instead of generator coroutines.
  • Removed Amp\asyncCall(): Replace invocations with Amp\async(), which starts a new fiber instead of using generators.
  • Removed Amp\coroutine(): There's no direct replacement.
  • Removed Amp\asyncCoroutine(): There's no direct replacement.
  • Removed Amp\Promise\timeout(): Future::await() accepts an optional Cancellation, which can be used as a replacement.
  • Removed Amp\Promise\rethrow(): Unhandled errors are now automatically thrown into the event loop, so there's no need for that function anymore.
  • Unhandled errors can be ignored using Future::ignore() if needed, but should usually be handled in some way.
  • Removed Amp\Promise\wrap(): Use Future::finally() instead.
  • Renamed Amp\getCurrentTime() to Amp\now() returning the time in seconds instead of milliseconds.
  • Changed Amp\delay() to accept the delay in seconds now instead of milliseconds.
  • Added Amp\weakClosure() to allow a class to hold a self-referencing Closure without creating a circular reference that prevents automatic garbage collection.
  • Added Amp\trapSignal() to await one or multiple signals.
Promise Combinators

Promise combinators have been renamed:

  • Amp\Promise\race() has been renamed to Amp\Future\awaitFirst()
  • Amp\Promise\first() has been renamed to Amp\Future\awaitAny()
  • Amp\Promise\some() has been renamed to Amp\Future\awaitAnyN()
  • Amp\Promise\any() has been renamed to Amp\Future\awaitAll()
  • Amp\Promise\all() has been renamed to Amp\Future\await()
CancellationToken
  • CancellationToken has been renamed to Cancellation.
  • CancellationTokenSource has been renamed to DeferredCancellation.
  • NullCancellationToken has been renamed to NullCancellation.
  • TimeoutCancellationToken has been renamed to TimeoutCancellation.
  • CombinedCancellationToken has been renamed to CompositeCancellation.
  • SignalCancellation has been added.
Iterators

Iterators have been removed from amphp/amp as normal PHP iterators can be used with fibers now and there's no need for a separate API.
However, there's still some need for concurrent iterators, which is covered by the new amphp/pipeline library now.

Closable

Amp\Closable has been added as a new basic interface for closable resources such as streams or sockets.

Strict Types

Strict types now declared in all library files.
This will affect callbacks invoked within this library's code which use scalar types as parameters.
Functions used with Amp\async() are the most likely to be affected by this change — these functions will now be invoked within a strict-types context.


Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate. View repository job log here.

@renovate renovate bot changed the title Update dependency amphp/amp to v3 chore(deps): update dependency amphp/amp to v3 Jan 30, 2023
@renovate
Copy link
Contributor Author

renovate bot commented Feb 13, 2023

Edited/Blocked Notification

Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.

You can manually request rebase by checking the rebase/retry box above.

⚠️ Warning: custom changes will be lost.

@spawnia
Copy link
Collaborator

spawnia commented Feb 13, 2023

Due to massive breaking changes, supporting both v2 and v3 seems hard, see https://amphp.org/upgrade. Perhaps we should just switch to v3 in our next major version, along with requiring PHP 8.1.

@simPod
Copy link
Collaborator

simPod commented Feb 13, 2023

Yup. Can we setup 16.0.x branch so we can start development? Also rename master to 15.1.x.

@spawnia
Copy link
Collaborator

spawnia commented Feb 13, 2023

I am not that eager to make the cut towards a new major version. As long as no one asks for changes that require breakage, I would rather develop the current version.

When we do make the change, I would split a 15.x maintenance branch and continue the current work on master.

@simPod
Copy link
Collaborator

simPod commented Feb 13, 2023

Sure, we can still develop current version but have 16.x alongside it already.

Similar case is e.g. with dbal https://github.com/doctrine/dbal where current is v3.6 but v4.0 is developed as well.

But nvm if you think it's a bad idea.

@spawnia
Copy link
Collaborator

spawnia commented Feb 13, 2023

I reckon the extra effort of maintaining multiple versions simultanously and merging between them is just not worth it for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants