What is the right time to get rid of [Obsolete]?

Topics: Developer Forum
Jun 12, 2013 at 6:43 PM
There's a number of Obsolete classes and methods in n2 due to bigger refactorings. It is good to keep them for a while so people know how to update their code, but there should be a time to delete them. I think that NOW would be a good time to make room for working towards 3.x.
If someone runs into a broken build after an update, he will have to go back to see the warnings and fix his code.

Thoughts?
/Stefan
Coordinator
Jun 13, 2013 at 2:33 AM
I think this is an excellent idea. Does anyone else have any objections?
Filed- https://github.com/n2cms/n2cms/issues/200
Jun 13, 2013 at 10:42 AM
This morning I upgraded old N2 site from 2009. As usually, upgrade went smooth. However, this was exactly the case where Obsolete attribute pointed me in right direction.

I understand motivation behind this initiative, cleaning codebase and polishing things, but on the other hand, my company produces at least 30-40 site annually. Satisfied customers return after 3-4-5 years with wishes for redesign, reimplementation or new features. In those cases upgrade to latest code base is first step, and that is where Obsolete comes real handy.

If we consider pros and cons, I see more cons. At least some of us will have harder life, and there is not too much benefits others will get. In everyday usage, you do not encounter Obsolete at all and it is not making problems. After all, there is a rationale behind introduction of this attribute.
Jun 13, 2013 at 3:35 PM
There's a cost of carrying obsolete stuff for too long, I'd say maybe one to three minor releases is appropriate. Leaving a project untouched for 3+ years seems like a very long time to me. Ok, in cases like yours you would have to do the upgrade incremental to get the benefit of the hints.

A more conservative alternative would be deleting on a major bump, e.g. when going to 3.x in this case you would have to update to the latest 2.x first, cleanup and then go to 3.x. (Or any other reasonable versioning schema that makes clear where bigger changes happen)

Obsolete files can be moved to a N2.Obsolete package, but obsolete methods are harder to deal with - we could derive from the new class and add the obsolete methods in the specialized version (also in N2.Obsolete package) - a matching DI container config would take care of getting you the version you want.

Finally obsolete methods could be wrapped with #if OBSOLETE to be optional. This would at least keep the namespace clean and binaries small.