Bitcoin Forum

Code tend to get cluttered up over time.
Often you think of a better way of doing something but have to support the 'old way' for backwards compatibility.

To get round this, you typically deprecate features (so that people know they won't be around forever) and then at some point in the future they get dropped. There are a few things now in MultiBit that fall into this category so I would like to propose a deprecation strategy.

+ Items that are planned to be dropped are initially deprecated, but will be marked with, say, "supported until end 3Q13". This means it is planned to be removed, but will be around until (at least) the end of the third quarter of 2013. There is a thread or wiki with all the items that are deprecated so people can see.
+ Items will typically be supported whilst deprecated for 2 full quarters (e.g. 6 months).
+ After that (when I get round to it) they will disappear.

A good example of this are the wallet info files. With a bit of work, all the data in the wallet info files could be put directly into the wallet files. This would have several benefits but you still initially need to write out the 'old' info files for old copies of MultiBit to work correctly.
You don't want to have to do this forever.
Thus, using the strategy above you might have:

1) Say in April I do some refactoring so that info files aren't required anymore. They are deprecated, with support until end 4Q13.
2) From April to the end of the year any new copies of MultiBit won't use the info files, but will still write them out for backwards compatibility.
3) Sometime after the end of 4Q13 i.e. after the end of Dec 2013, I will then drop the backwards compatibility i.e no more info files will be written and I can tidy up the code.

This is just an example.

For the user it means that they will should have 6 months of backwards compatibility between versions.
For me it means that every quarter I can tidy up the code a bit and get rid of the baggage that inevitably accretes.