[question]Will there ever be a BC-break ?
greg0ire opened this issue · comments
Not a bug:
Nice point from /u/0xRAINBOW on reddit today : what will happen if httplug gets a BC-break one day? Do you plan on never getting one? Or would there be a new composer package for that? Otherwise I guess there would be the same problem as before : conflicts between libraries that depend on different versions of httplug.
That is an excellent question. I do not believe we have discussed that as a team. But here is my point of view:
BC breaks are the devil in these kind of wide-used packages. That's why we have kept the packages as small and as SOLID as possible. Some people complain about that it is too many packages but that is a good thing. Small packages with specific features is more stable by definition. And we have worked hard to make sure to reach a "perfect"/stable state.
My idea is that php-http/httplug will be replaced by 2 or more PSRs. That process is very long and will probably be years before we can (not "will") deprecate php-http/httplug. The PSRs will of course be backwards compatible with php-http/httplug.
I consider php-http/httplug as a pseudo-PSR in many ways. Ie, releasing a version 2.0 should be avoided as much as possible.
Small and SOLID should indeed make BC-breaks less likely to happen… and the slow and steady 0.x to 1.0 phase probably allowed you to get rid of design mistakes if there were any.
so far they do not "namespace" a version 1. the problem would not be solved by "simply" doing a different package name. its also the namespaces of the classes.
Indeed.
do you have suggestions? did fig discuss their policy on this?
I was just curious about the plan if there was one. Now that I think of it, a solution if you are forced one day to release a version 2 could be to use php-scoper. I'm really not sure this is usable outside a phar though… and there is no stable release ATM.
On the design level, I'd say isolate as many interfaces / abstract classes / high level things as you can into a separate package, so that you can change the rest without worrying, but what @Nyholm says makes me think you are probably already doing this, so… good job!
Closing this b/c I don't want to pollute your issue tracker with something that is a discussion, but feel free to reply ofc.
Just link to http://semver.org/? I assume semantic versioning is used.
semver is not enough in this case. semver is a promise that upgrading a minor version does not break anything. but for httplug, doing a 2.0 would create quite a mess. if 1 and 2 are really incompatible, libraries using httplug would need to either do horrible hacks or limit to only 1 or only 2. as soon as your project uses several libraries that depend on httplug, the later will end up in being limited in what you can use because some lib will be on httplug 1 and another on httplug 2.
@dbu gist of what?
@sagikazarmark : if I may answer, the fact that you are commited to avoid BC-breaks forever, and will enforce good design principles to achieve this goal. At least that's what I take away from this discussion.
Well, that should be kind of obvious IMO