: - since lucene is on a new major version, the next solr release : containing that sould have a new major version number
This rationale concerns me less then making sure the version change adequately communicates the significance of "upgrading' to users ... ie: if most/many users will need to make config changes in order to upgrade, that seems like a "major" upgrade to me, and the version number should change in a "major" way ... if that means 2.0, 3.0, 10.0, or 3.1 i don't care. : - for simplicity, and the "single dev" model, we should just sync : with lucene's... i.e. the next major Solr version would be 3.1 this concerns me a little in that it doesn't feel like we've really talked through how exactly we expect the version number game to play out over time ... even if we get Lucene-Java and Solr onto the same scheme now, we could easily find ourselves in a situation where we're ready to release lucene-3.3 (ie: a minor release that is back-compat with lucene-3.2 and addss some new features) but we also want to release a new "major" version of solr that breaks compatibility with solr-3.2 ... so what do we call that? in short: trying to sync version numbers seems like a pain with very little beenfit -- version numbers should communicate significance of change, not dependency information. : - remove deprecations (finally!), and perhaps some additional cleanups : that we've wanted to do As long as we bump the major version number to communicate the significance, i'm all in favor of purging deprecations anytime people want. -Hoss
