Salomon, That would be pretty awesome! Its something we have had a pretty consistent issue with and something we absolutely need to solve.
Eric On Thu, Oct 28, 2010 at 11:24 AM, Salomon Elizondo <[email protected]> wrote: > Hey, I won't be able to make the phone conference, but I just wanted > to volunteer my time in possibly helping out with system automation > for compiling/testing on whatever the supported platforms are using > buildbot or any other application the group picks. > > Thanks, > Salomon > > On Wed, Oct 27, 2010 at 5:29 PM, Martin Logan <[email protected]> wrote: >> 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]. >>> 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. >> > > -- > 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. > > -- 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.
