mirror of
https://github.com/wiremock/WireMock.Net.git
synced 2026-01-11 21:10:32 +01:00
Classes are marked as obsolute before new ones are available #217
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @mikravn on GitHub (Oct 14, 2019).
Hi,
It seems that several classes were marked as obsolete before any alternative is available.
As a consumer of the package that means that we get several "unfixable" warnings on the current version.
I firmly believe that you should not obsolete classes prior to making the new ones available, as it forces a massive amount of warnings on all of our projects.
Referenced commit:
31f3d77b38@StefHEdit: If your project is setup to generate errors on obsolete code, then you can imagine the amount of pain this commit causes.
@StefH commented on GitHub (Oct 14, 2019):
Hello @mikrj , thanks for your comments.
My idea is that I mark some classes + interfaces as obsolete, in order to replace/remove these in the next version.
Most things are namespace changes, or do you see that differently?
About the
WireMock.Net.StandAlone: my idea was to make this obsolete, but if this causes troubles, I can re-introduce it again.@mikravn commented on GitHub (Oct 15, 2019):
Hi StefH,
I was mostly referencing e.g.
WireMock.Net.FluentMockServer, not personally usingWireMock.Net.StandAloneso I am not sure what the use case is there.I believe that you should not obsolete the classes (e.g. FluentMockServer) until there is an alternative available, as it forces warnings/errors onto the consumers of the current version; which for some projects may give red builds.
I think that it is perfectly fine to obsolete the old classes (e.g. FluentMockServer) once the new classses are available (e.g. WireMockServer) if the old classes are left in place for backwards compatibility for a few versions.
If the old classes are removed immediately at introduction of the new classes (breaking change), then I think that you should just skip the obsolete annotation all together.
@marcinbudny commented on GitHub (Oct 18, 2019):
Hi StefH,
The proposition by mikrj is very reasonable and it is the way most libraries make apis obsolete. I would also like to suggest bumping the major version when doing breaking changes, so that the library is compliant with SemVer.
@StefH commented on GitHub (Oct 18, 2019):
Hello @marcinbudny and @mikrj,
Thanks for your suggestions.
What I can do is:
1
When some pending PR's are merged to master, I will also already add the new WireMockServer class and make sure the old/obsolete FluentMockServer can still be used
The version will be like in the old range, so something like
1.0.342
The obsolete classes will be kept for some time (~ 3 or 5 releases) in the
1.0.*range3
The obsolete classes will be removed and the version will be set to
1.1Is this acceptable?
@APIWT commented on GitHub (Oct 21, 2019):
I think this suggestion is very important. If you make breaking API changes, bumping the major version number (ie: bump from
1.0.34to2.0.0) is very helpful for someone upgrading packages in their project.EDIT: Also check this out: https://semver.org/spec/v2.0.0.html#how-should-i-handle-deprecating-functionality
@StefH commented on GitHub (Oct 25, 2019):
Hello @marcinbudny @mikrj @APIWT @prestonj,
Thanks for your suggestions.
What I will do is:
For the next version (1.0.35 in a few days) , I will remove these Obsolete annotations.
The version 1.1.x will introduce the new classes (e.g. WireMockServer) and the old classes will proxy to these new classes (e.g. FluentMockServer).
The version 1.1.x will continue for some releases (~5)
In version 1.2.x I will add the Obsolete annotations
In version 2.0.x the obsolete classes will be removed
Can this work for you?
@mikravn commented on GitHub (Oct 25, 2019):
Hi @StefH,
The above will work fine for me, thanks a lot.
@mikravn commented on GitHub (Oct 25, 2019):
@StefH can you close issue when obsolete annotations are removed?
@marcinbudny commented on GitHub (Oct 25, 2019):
Hi @StefH ,
Sounds great. Thanks.
@ipatalas commented on GitHub (Nov 21, 2019):
I think the change is already available in the most recent version so the issue can be closed.
It misled me at the beginning, had to check CHANGELOG to figure it out.
@StefH commented on GitHub (Nov 21, 2019):
@ipatalas I'm not sure I understand what you mean?
@ipatalas commented on GitHub (Nov 21, 2019):
What I mean is that this issue is no longer valid - the [Obsolete] attribute has been removed in the latest version so this issue can be closed.
Otherwise it can mislead more people in thinking that this has not been solved yet and they need to wait.
@mikravn commented on GitHub (Nov 21, 2019):
Resolving it