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. 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. On Oct 27, 1:36 pm, Samuel <[email protected]> wrote: > > I can agree with you on ktuo, we should have deprecated it at least across > > one major version change. I am currently putting together some erlware > > standards for our consideration. I will certainly add the deprecation > > approach to them. > > Just a couple of things here. > > 1 - It's true, the deprecation procedure it's not clear; "major > version change" may mean different things for all of us. For me, > 0.5.0.0 looks like quite major because the two trailing zeros, but > also somewhat minor because of the leasing zero. So, yes it is not > clear what's major > > 2 - Since it's not clear, it cannot be assumed anything in either > ways, so I disagree with the statement "When you deprecate an API, you > do NOT make it throw > an exception and break everyone's code that uses that API," That > depends on how the team wants to handle backwards compatibility. In > this case we (I suggested it) decided not to waste efforts maintaining > an api that was wrong. We could also decide to invest efforts in doing > so, at the cost of not doing other stuff, yes, but we didn't > consciously. And that was discussed in the list if I'm not mistaken. > > So the problem here is that Edwin assumed that backwards compatibility > was guaranteed, and it was not. In my view, this is a versioning issue > and a communication problem, but I don't see anything wrong in the way > ktuo moved forward. > > Maybe Edwin had to upgrade ktuo for some reason, maybe it was upgraded > by mistake by the tools (that would also be wrong). The thing is, if > you need to upgrade for some reason to latest ktuo version, and you > need it to be compliant with your code, and you are not willing to > change your code, then someone could put effort in porting the old > ktuo api to the new version. There are a lot of 'ifs' and a 'could' in > that sentence. If they are not met, dragging old, broken behaviour is > just a plain waste of time. I suspect that Edwin didn't need to > upgrade ktuo at all, so restoring an old version, as you are already > discussing, should close the issue. > > 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.
