> Samuel, > > I didn't upgrade ktuo. I upgraded sinan and it upgraded ktuo from > 0.4.0.3 to 0.5.0.0. Since ktuo was in the Erlang code path, the newer > module got precedence.
Ok, that was my concern. The serious problem was not breaking compatibility in ktuo, we can discuss a lot on whether was good or bad idea. What really shouldn't ever happen is that you got a library upgraded without knowing it. In my opinion, that's way more important than deprecation policies (whether old apis should be maintained or not), since if library users can decide whether they want to upgrade or not, then library writers can adapt their policies according to their users needs. If libraries get updated randomly, then library writers have to waste effort maintaining code, whenever is needed or not. For example, in this case. We needed an incompatible change in ktuo since the api was not orthogonal. This change will be of interest for new developments only, old developments could safely continue using the old api. And if there is much interest in that line, the community may want to invest effort in maintaining it. Since we screwed up making you upgrade ktuo without your consent, we broke your code and upset you. Of course, once that undesired upgrades are avoided, a clear deprecation policy will help. There are simple rules to make version numbers informative enough so that you know whether it's save to upgrade or not. > I don't think it's too much to ask leaving the old API there, bugs and > all, and adding a new API with a different name to keep backward > compatibility. You can delete the old code later when people have had > a chance to upgrade. It's a valid approach, but I (maybe we) assumed that old api users will never upgrade unless they wanted to adapt their code to the new API. Having two different implementations in the same library have the advantage you mention, but it also clutters the code and may lead to confusion. So under the (wrong) assumption that old code will keep using the old version, keeping the two versions of the API in the code has more disadvantages than advantages. > A perfect example of how I would do it is mochiweb. They created an > entirely new JSON module, I think called mochiweb_json2.erl, and still > distributed the old one. This lets users upgrade gracefully and put > the onus on the owner of the software to change the software (e.g. > sinan) to use the new API/module/whatever without breaking anything. > This would have been a much better way to handle it, and our code > would not have broken. You could have distributed ktuo2 and not broken > anything at all. I would be surprised if you don't see the sense in > that. Yeah, I see sense on in that, and I did similar things in large libraries when some api needed to be refactored, but refactoring all the code depending on that api was not viable, for example. But I also see there is sense in the other approach, avoid cluttering things that need not be cluttered, and avoid investing time maintaining things that are not needed. Ktuo is a small library that does a simple job, having two modules doing the same with different apis just to parse and encode JSON terms seems overkill for me. I hope we came to terms now. You may have a more keep-backwards-compatibility view and I may be more aggressive cutting time investments in old stuff and simplifying apis to the maximum. There is a balance point somewhere and we sway around in different ways. I agree we screwed-up with ktuo but I insist, and I think it's what erlware should put effort to avoid a new episode like this: It is really important that erlware becomes more careful upgrading libraries that other developers are using. Regards -- Samuel -- You received this message because you are subscribed to the Google Groups "erlware-dev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/erlware-dev?hl=en.
