mbraceproject / FsPickler

A fast multi-format message serializer for .NET
http://mbraceproject.github.io/FsPickler/
MIT License
324 stars 52 forks source link

API breakage in minor version? #63

Closed haf closed 8 years ago

haf commented 8 years ago

It seems a minor version has broken its API contract!

https://github.com/SuaveIO/suave/pull/302

Could you please revert the above mentioned change?

eiriktsarpalis commented 8 years ago

Duplicate, c.f. https://github.com/nessos/FsPickler/issues/61

haf commented 8 years ago

I'm sorry, but I can't find the commit where you reverted the breaking change. Where is it?

eiriktsarpalis commented 8 years ago

Oh, there isn't one. What problem would performing such a reversion fix?

haf commented 8 years ago

Pain-free package management when using Suave. I care about my users and they should be able to trust semver with us.

eiriktsarpalis commented 8 years ago

So I'm assuming that you are using a < 1.3.0 version in Suave which happens to break when users request later versions?

haf commented 8 years ago

Yes

eiriktsarpalis commented 8 years ago

Is upgrading to something >= 1.3.0 out of the question in Suave itself? Given that there have been 9 releases since 1.3.0 that effect the naming change, I do not see how moving back to the original naming would do much to avert errors and confusion.

haf commented 8 years ago

The point is not that we can't upgrade Suave, of course we can, and I did, which broke the build. The point is that there's no way, from looking at the version numbers, to know how to compose different versions of the packages together.

Since we haven't released this breaking change, I'd say we'd gain a lot from reverting; it's not been that long in wall-clock time.

You would indeed avert errors by this course of action. Just unpublish the broken nugets, bump your major version and push that. Then, either we upgrade, or we stay behind for compatibility reasons. I could give you an in-depth description of how package changes like this interact, but I don't because it's as boring to write about as it is to fix... ;)

eiriktsarpalis commented 8 years ago

What exactly is causing your build to break? If I remember correctly the only change effected in 1.3.0 is that particular renaming (adding the Serializer suffix in all the serializer factory methods). If you want I can have a look at your code.

The change might have broken backwards compatibility (as iterated in #61 we have not adopted semantic versioning), but it is a change that improves the overall quality of the library and as such I think it should not be reverted. Also, unpublishing nugets does not make them go away; a project configuration which explicitly references, say, 1.3.0 would still fail to build. In other words, I do not see how breaking backwards compatibility twice will have some sort of cancellation effect.

If it helps at all, we will try to keep upcoming 1.x releases (whose development is strongly tied to the upcoming MBrace 1.0) stable w.r.t the main serialization APIs (there is no plan to change any of these atm) and seriously consider semantic versioning for >= 2.0 releases.

eiriktsarpalis commented 8 years ago

This should probably fix your problem: https://github.com/SuaveIO/suave/pull/303