search

10up / wp_mock

WordPress API Mocking Framework
https://wp-mock.gitbook.io
Other
676 stars 70 forks source link

v1.0.1 is not available on Packagist #241

Closed thomasfw closed 10 months ago

thomasfw commented 10 months ago

Bug report

v1.0.1 is not available on Packagist - https://packagist.org/packages/10up/wp_mock

Replication steps

N/A

Expected behavior

N/A

Logs 

Problem 1
    - Root composer.json requires 10up/wp_mock ^1.0.1, found 10up/wp_mock[dev-refactor/move-hooks-component-in-own-namespace, dev-trunk, 0.1.0, ..., 0.5.0, 1.0.0] but it does not match the constraint.

Screenshots

N/A

unfulvio-godaddy commented 10 months ago

hey @thomasfw you are absolutely right, looks like we forgot to update composer.json version in the last rollout; however, the version in composer.json may not be required and perhaps we could drop it altogether to avoid this type of issue in the future

in the meantime this is fixed you could use dev-trunk as 1.0.1 in your composer dependency version; it would load the current main branch which is up to date to 1.0.1 (we haven't pushed new code since so it should be alright)

thomasfw commented 10 months ago

No problem, will use dev-trunk for now - thanks

thomasfw commented 10 months ago

Can I ask whether you'll be tagging a new release with the fix in 48b7f22934a4351e45e336f09263ee27fc9ddcbe, or will this be included in a later version?

Edit: I should add that this isn't fixed until a new version is tagged, otherwise packagist won't pick up the changes. The package remains incompatible with PHP 8.3.1 when installing with composer (@unfulvio-godaddy)

BrianHenryIE commented 8 months ago

Looks like that is on Packagist now. You can configure a webhook from GitHub to Packagist to run on tags. It's very easy to set up but I see a comment that you don't have full access to Packagist to do that. Still, Packagist polls GitHub to look for updates too.

In the Composer documentation it says:

In most cases [version] is not required and should be omitted [from composer.json]

So I think the problem was correctly fixed with #242, and that #244 should not be implemented.

unfulvio-godaddy commented 8 months ago

indeed it wasn't needed all I had to do is to republish the package here (dropping the composer version happened after we tagged 1.0.1); so retagged using the latest from trunk (which only contained the version drop from composer) and that fixed it in Packagist