🥳 Release v1.0 🎉

[Potherca]

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.

• Open discussion: rename the default branch ? #160
  (resolved by Rename references to master branch #199)
• Rename the namespace #188
  (resolved by Rename namespace prefix from Dealerdirect to PHPCSStandards #191)

Todo directly after v1 release

These should be completed just after the release.

• Question: new round of changing the "type" suggestion PRs ? #155

Out of scope for v1

These can be completed later.

• Iterate further on the integration tests via Travis #92
• Removal of search depth without dependency change does not update installed paths #150
• Absolute vs relative paths #156
• Error: dealerdirect/phpcodesniffer-composer-installer contains a Composer plugin which is blocked by your allow-plugins config.  #185
• Rename Package for Composer/Packagist #159

[jrfnl]

@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?

---

• Iterate further on the integration tests via Travis #92

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.

---

• Removal of search depth without dependency change does not update installed paths #150

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.

---

• Absolute vs relative paths #156

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.

---

• Rename Package for Composer/Packagist #159

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, 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.

---

• Error: dealerdirect/phpcodesniffer-composer-installer contains a Composer plugin which is blocked by your allow-plugins config. #185

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

[jrfnl]

One thing not mentioned in the above (but mentioned in comments in ticket #159) is "updating the namespace of the plugin to be in line with the new organisation the repo lives in".

As that could be regarded as a breaking change on the off-chance that there would be a package extending or build on top of this plugin, I'd be in favour of doing this and doing this before the 1.0.0 release.

I've opened #188 to discuss this further.

[Potherca]

Regarding changing the Packagist name, I would really like to do the rename but in a backward compatible manner. I have no idea how but I might be able to come up with something if I manage to find some time to allocate to the task.

In the mean time, actionable tasks that can already be resolved are:

• Rename the namespace to whatever is decided in the relevant issue

And possibly:

• Rename the master branch to main

Are there other, non-code tasks we might still have to do?

[jrfnl]

Regarding changing the Packagist name, I would really like to do the rename but in a backward compatible manner. I have no idea how but I might be able to come up with something if I manage to find some time to allocate to the task.

Maybe we should ask @Seldaek if that's even possible ?

[jrfnl]

Are there other, non-code tasks we might still have to do?

Prepare a human readable changelog which clearly lists any breaking changes ;-)

[Seldaek]

If you want to rename see composer/packagist#47 (comment)

It's BC for users as the old name keeps working but I'd only do it if it's worth annoying every single user with the abandoned status etc.

[jrfnl]

@Seldaek Thank you for confirming that renaming like that is still the only way to do it.

[Potherca]

We will be releasing v1.0.0 today and renaming the master branch to main.
Renaming the composer package has been relegated to a later time (see #159).