It is nice to be back. We have a lot of work to do as a project. After 2+ years with minimal support we have our work cut out for us to get to where we want to go. This has already started. Edwin, I hope you will help us go over the project standards we are drafting as rules for ourselves which will in the end prevent this sort of mistake from happening again. We are touching on areas as:
Coding Standards Testing Standards Officially supported platforms Versioning and Deprecation Cheers, Martin On Wed, Oct 27, 2010 at 3:43 PM, Edwin <[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. > > 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]<erlware-dev%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/erlware-dev?hl=en. > > -- 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.
