On Wed, 18 May 2011, Chris Travers wrote:
probably a good idea to find a mode where releases get only big enough to address a small number of specific issues (and the regular bug fixes) on the point releases. That might satisfy only a small group of current users, but the continued development could easily attract new users too. That would be a net benefit.Question: How should we look at getting rid of the old code, post 1.3?
I will trust that you are not talking about 2.0 here. Because down that way lies madness, at least if 1.3 is ever to happen.
Why not start phasing out (by rewriting) SL/old code, during the sub-releases of 1.3? After the main release of 1.3.0, set a list of things to be rewritten. As bugs are fixed, etc., and new versions are released, the replacement code can be incorporated with no real notice to the users.
Maybe by the time it gets to 1.3.20 or so, it will be purified. That would be my suggestion.Internal dependencies will have to be figured out for each section to be replaced, and a nightmare it will be, but if you plan to port any of it forward in bulk, then doing it slowly may be the best way.
That said, sadly, since we already know that the plan for 2.X is for a new codebase (or was, at least), I doubt many will be willing to do the work.
So ultimately, maybe my suggestion should be to just leave it alone if it works, and replace it if it don't.
Luke