I hope this is mostly a one-time change, and that there are substantially no warnings to fix going forward.
There aren't many (any?) outstanding patches now. But there will be later, and changes harder to make. At version 0.4, no problem. At 1.4 with lots of dependent users, not so much. So that is why I want to get in these changes before the code starts to "congeal" and we start to say things like, well, yeah would have liked to adjust that but it would break X now... such is the root of all code base rot in my experience. Speaking of, would like to keep trimming out unused math code, but perhaps better to encourage those that know more about what's used and not to have a go. It's pretty easy in IntelliJ -- just grays out methods that aren't in use now. On Wed, Sep 15, 2010 at 10:02 PM, Grant Ingersoll <[email protected]> wrote: > This kind of stuff is generally why many projects either forgo cosmetic > changes or make them automatic via SVN hooks or something similar. Large > cosmetic changes often make it next to impossible to apply patches w/o a lot > of work that were submitted previously, thus leaving you as the committer to > then go pester the original contributor to update to trunk instead of you > just being able to apply the fix. > > An alternative might be to apply all cosmetic changes at release time, after > code freeze and just make reasonable efforts in the interim, but nothing > sweeping.
