On 20/02/2010, at 12:01 PM, Jacopo Cappellato wrote: > > On Feb 20, 2010, at 6:49 PM, Adam Heath wrote: > >> Jacopo Cappellato wrote: >>> Adam, >>> >>> what you say is right but it is also true that if a development team was >>> able to create a custom application on OFBiz, it should also be able to >>> figure this out quite easily. >>> Everyone in the software industry is aware that after an upgrade the >>> tools/framework used to build a custom application, some tests and fixes >>> are required. >> >> Sure, everyone is aware that upgrades of systems we use require us to >> change our own systems to follow suit. However, what I am saying is >> that how will our users know what they have to change? >> >> I am willing to say that, in this particular case, we don't need to >> have deprecated classes stay in the old location. However, we still >> need to document the move. If it doesn't happen now when the move >> occurs, will we remember to do it right before we release? Is your >> memory really that good? > > > Again, I agree with you and I also agree that documenting this change is a > good idea. > But I still think that this specific issue could be discovered and fixed > (even without documentation) by a decent developer in less than 20 minutes > after a system upgrade. > If there is a document it is even better... > > Jacopo
That's why I was in favor of using deprecation, it's a fantastic form of documentation. Every time you compile it's there in your face telling you that you need to change something and what to change it to. 20 minutes may sound fine, but it's the accumulation of at least years worth of these types of changes multiplied by the number of people affected by them. When you look at it in those terms it is a fairly expensive strategy. Regards Scott
smime.p7s
Description: S/MIME cryptographic signature
