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.
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. 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. On Oct 28, 2:19 am, Samuel <[email protected]> wrote: > > Owners of a code base are entitled to decide exactly how to update an > > API. It's their code, after all. > > > However, search engine results are packed with too many real-world > > examples of, and rationales for, maintaining backward compatibility at > > the API level to justify arguing about it here. > > It's not matter of who has rights to modify the code, that's obvious. > The point is you argue that breaking compatibility in ktuo was a > mistake and I argue that it wasn't. Looking backwards, and without any > further information from your side, I still would've done it. > > Of course, your code broke and you were upset. That means something > went wrong. In my view, what went wrong was that I believe you didn't > need to upgrade ktuo. You might have upgraded it without knowing it > (probably fault of the tools) or you might have upgraded it assuming > that it wouldn't break compatibility (part your fault for upgrading > blindingly, mostly fault of not having a clear versioning policy and > release notes). > > Saying that are many real-world examples is not an argument, there are > examples and rationalities for both opinions; I won't start an example > war. In some cases it's needed to keep backward compatibility, in > other cases it is not. Since backward compatibility increases software > complexity, it costs time now and in the future, so it has to be done > only when there are good reasons to do it. And in this case, I still > don't see any. > > So the big questions are: Why did you upgrade? Did you really need to > upgrade?, and Had you had all the information about incompatibilities, > would you've perceived it as a problem? > > > When code is free, as in beer, the only real recourse to a serious > > disagreement about the software development policies of the code > > owners is to exercise one's freedom of choice and stop using it. > > There is a second option and is discussing about decisions and reasons > behind them, rather than about isolated facts without context. That's > good for both sides unless, as you say, there is a serious > disagreement. > > 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.
