jrfnl
commented
1 year ago @Potherca Thanks for opening this ticket.
Here's my two cents regarding the "To be decided" tickets, which I largely base on semver reasoning:
Should these be completed before the release?
The base functionality of the plugin is currently safeguarded by tests in a much better way than ever before (which is the trigger to tag as `1.0`). Additional tests are definitely welcome, but can be added at any time as tests don't ship with the release anyway.
Conclusion: does not need to be in the 1.0.0 milestone.
This is a bug discovered while working on the tests for this option. This bug has not been reported by end-users.
And if we follow semver, bug fixes can go in any time, patch, minor, major, so this is not a blocker for the 1.0.0 release.
Note: the "fix" for this one, may even just be a documentation update (recommend re-running the plugin manually after a change to the `phpcodesniffer-search-depth`).
Conclusion: does not need to be in the 1.0.0 milestone.
This needs additional discussion and research (see the ticket).
If we'd choose to fix this for the `1.0` release, we could change the "default". If we leave it till later, we can still action this without it being a breaking change by leaving the default as-is and adding an option which users can choose to use (or not).
Adding the option can be regarded as an enhancement which can go into any minor. Changing the default value of that option to one which would change the behaviour of the plugin can then be done in a `2.0` release.
Then again, if more user reports come in related to this, changing the default could be regarded as a bug fix and could go into a minor (as the adding of the new option is an enhancement, so should be in a minor).
Conclusion: does not need to be in the 1.0.0 milestone.
If we action this, I'd favour doing so just before the `1.0` release as people would need to update their `composer.json` anyway to allow for the `1.0` version.
Note: current download count the project would "lose" in > 36M.
Then again, what with the changes in Composer 2.2, I'm not sure we should action this at all, as the burden on end-users is now exponentially larger if we change this.
* Originally, only people who would `require[-dev]` the plugin would need to make a change. If projects inherited the use of the plugin via one or more of the external PHPCS standards they use, the name change would not require action on their side (only on the side of the external PHPCS standard).
* Since Composer 2.2, any project using this plugin - whether they `require[-dev]` it directly or inherit it from an external standard - needs to have the `config - allow-plugins` directive in their `composer.json` for this plugin.
As the `config - allow-plugins` directive is _package-name-based_, those `allow-plugins` configs would **_ALL_** need to be updated on a name change, so the end-user impact/burden on maintainers is now much much larger.
Based on the [dependency-graph](https://github.com/PHPCSStandards/composer-installer/network/dependents), this would now impact > 42K projects and that's only the projects which are public and published on GitHub, so the real number of projects which would be affected by this change is likely to be double that or more.
I would say that this is a "now or never" decision and taking the above into account, I lean towards "never".
Conclusion: decision should be taken before releasing 1.0.0.
This was a support question about the Composer 2.2 change regarding `allow-plugins`. AFAICS there is nothing we could do to make things easier. IMO this ticket should be closed as "answered".
Conclusion: does not need to be in the 1.0.0 milestone.
All in all, the above aligns with those tickets already in the 1.0.0 milestone: https://github.com/PHPCSStandards/composer-installer/milestone/3
Potherca
Seldaek
With all of the hard work, changes and improvements over the last year (or two), we have reached a point where we can confidently say that this project has matured to a stable point.
Because of this, we will be releasing v1! 🥳🎉
This ticket is meant as a central point to coordinate what needs to be done for this release.
I think the first point in order is to decide which task belong in the v1 workload and which can be postponed until later. Non-code or non-repo changes should also be listed for thing we want to happen when the release has been deployed (like community outreach). Tickets could be made for those but that feels a bit like overkill.
Within scope for v1
These should be completed before the release.
160
(resolved by #199)
188
(resolved by #191)
Todo directly after v1 release
These should be completed just after the release.
155
## Out of scope for v1
These can be completed later. - #92 - #150 - #156 - #185 - #159