> for maintaining the code. There would also be a high probability of trunk > never being in a releasable state, given the chance of there being a > half-baked idea in trunk that we don't want to be bound to for the rest of > Solr's lifetime.
: I'd tend to disagree: committing the patches to trunk allows widespread : testing and the chance for wider review of the code to see if it does : what it should. Only when the code is part of a release is there any : obligation to a proper lifecycle (ongoing support, deprecation, then : finally removal). True .. but once something is commited it's hard to extract if people decide they are unhappy with the API/implementation prior to a formal release. The general philosophy about committing in Solr is outlined on the wiki... http://wiki.apache.org/solr/CommitPolicy -Hoss
