I'm with Aleksi on this one. Semantic version out the old name, then remove in following version release. Any logic that has to be carried over from the old to the new should be moved and tests created to validate functionality.
1.0.0 = Added SomeClass
2.0.0 = SomeClass deprecated, use NewClass
3.0.0 = SomeClass removed use NewClass
As a production system maintainer I always lock my dependencies to major release version. (If a library does not use SemVer, I don't use that package.)
Deprecating existing functionality is a normal part of software development and is often required to make forward progress. When you deprecate part of your public API, you should do two things: (1) update your documentation to let users know about the change, (2) issue a new minor release with the deprecation in place. Before you completely remove the functionality in a new major release there should be at least one minor release that contains the deprecation so that users can smoothly transition to the new API.
Maybe that was unclear (I wrote this in a rush), but this blog post is about how you can implement that part of SemVer (deprecating part of your public API) for php types. Not sure what "It" is referring to in "It's not an implementation issue IMO" or why you two attempt to teach me the basics of SemVer when I'm trying to show how to put it in practice for a specific part of a PHP API.
This solution is enough in some situations. In others, you will need inheritance, and in some more complicated situations, you will have to resort to class aliases. That's what I failed to make perfectly clear in my article.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This will not be enough, sadly. I need to make the new type usable everywhere the legacy type is.
I'm with Aleksi on this one. Semantic version out the old name, then remove in following version release. Any logic that has to be carried over from the old to the new should be moved and tests created to validate functionality.
As a production system maintainer I always lock my dependencies to major release version. (If a library does not use SemVer, I don't use that package.)
Not sure I understand. Please show me how you would implement a Foo class that would pass the following tests:
github.com/greg0ire/type_deprecati...
It's not an implementation issue imo. This is from Semantic versioning homepage:
Maybe that was unclear (I wrote this in a rush), but this blog post is about how you can implement that part of SemVer (deprecating part of your public API) for php types. Not sure what "It" is referring to in "It's not an implementation issue IMO" or why you two attempt to teach me the basics of SemVer when I'm trying to show how to put it in practice for a specific part of a PHP API.
Ah, with "it" i mean deprecating a type in php. As far as i'm concerned this is enough:
But i also accept the fact that i may have missed some point in this article...
This solution is enough in some situations. In others, you will need inheritance, and in some more complicated situations, you will have to resort to class aliases. That's what I failed to make perfectly clear in my article.