2.0.0 readiness check

[michaelmoussa]

@weierophinney since there are a number of pending releases in various repos that may be affected (or depended on) by this, can you give this a quick sanity check before I release 2.0.0?

Process after 👍 :

1. Rebase to update CHANGELOG.md from 1c7411f to reflect what the actual release date will be.
2. Rebase with upstream/master and force-push the updated master to my fork (which will update this pull request).
3. Merge the pull request.
4. Tag 2.0.0 off of whatever the new commit hash for 1c7411f ends up being.
5. Follow the remaining release steps to bring develop into sync with master.
6. Delete the dev-2.0.0 branch.

End result should be that 2.0.0 is released, develop and master are in sync, dev-2.0.0 is deleted, and there is no unreleased code in any branch or PR (at the time this PR was submitted).

Make sense?

[coveralls]

Coverage remained the same at 100.0% when pulling 63a8fd7d143a4636b45bbba503421dd59a47669a on michaelmoussa:master into 50c9e4dff0cf65d9937c56b597c530e1bf5f8ef0 on zendframework:master.

[coveralls]

Coverage remained the same at 100.0% when pulling 1c7411f626919cffb901e22e34de76ead598e61a on michaelmoussa:master into 50c9e4dff0cf65d9937c56b597c530e1bf5f8ef0 on zendframework:master.

[michaelmoussa]

My understanding, then, is that once this is merged and 2.0.0 is created, we will need to create new major or minor versions of the router implementations that pin to the new major version presented here, so that they can update their implementations of the RouterInterface; is that correct?

Yes. I think they'd need to be major, though, wouldn't they? If someone is simply letting Expressive do it's thing, then they wouldn't be affected by a change to the interface, but if anyone has actually implemented that interface, their implementation will be missing the new parameter.

[weierophinney]

Yes. I think they'd need to be major, though, wouldn't they? If someone is simply letting Expressive do it's thing, then they wouldn't be affected by a change to the interface, but if anyone has actually implemented that interface, their implementation will be missing the new parameter.

I realized that later myself. Additionally, it's more an issue for folks extending the implementations; the extensions, if they override that method, would be broken at that point if they do not define the additional, optional argument. As such, agreed that we need new major versions.

[coveralls]

Coverage remained the same at 100.0% when pulling c4526c38947088cdc86a3e70304043ca7cdb6e26 on michaelmoussa:master into 50c9e4dff0cf65d9937c56b597c530e1bf5f8ef0 on zendframework:master.

[coveralls]

Coverage remained the same at 100.0% when pulling 49373a33fe6852470f50cb2f164e0003611c3cf8 on michaelmoussa:master into 50c9e4dff0cf65d9937c56b597c530e1bf5f8ef0 on zendframework:master.

[michalbundyra]

@michaelmoussa about commit c4526c3 please see: https://github.com/zendframework/zend-expressive/pull/418#issuecomment-270484049

... so you shouldn't update year in files you didn't change.

[michaelmoussa]

Thanks @webimpress, I hadn't seen that comment, but removing the update causes the license check to fail. How should I proceed, @weierophinney ?

[weierophinney]

removing the update causes the license check to fail. How should I proceed

Change the following in .docheader:

%regexp:(20\d{2}-)?%%year%

to read:

%regexp:(20\d{2}-)?20\d{2}%

That will allow it to keep existing date ranges; unfortunately, it also has the side effect of not enforcing the current year for new files. I'll see if I can work with the author of the license checker library to figure out something more robust for the future, but the above will get us moving forward.