On 5/21/2009 at 7:17 AM, Michael McCandless wrote: > OK so it sounds like we've boiled the proposal down to two concrete > changes to the back-compat policy: > > 1) Default settings can change; we will always choose defaults > based on "latest & greatest for new users". This only > affects "runtime behavior". EG in 2.9, when sorting by > field you won't get scores by default. When we do this we > should clearly document the change, and what settings one > could use to get back to the old behavior, in CHANGES.txt. > > 2) An API, once released as deprecated, is fair game to be > removed in the next minor release. > > We still only make bug fixes on point releases, support the index > file format until the next major release -- those don't change.
Contrasting the upgrade experience of existing "maintenance" users (i.e., users not using new Lucene features) under current policy with their experience under the above proposals: Currently there are two upgrade experiences for these users: a) upgrading within the same major release; and b) major release upgrades. For a), the user reads CHANGES for back-compat exceptions, but otherwise has drop-in compatibility. For b), the user performs two upgrades: first, just like in a), to the last minor release in the same major release, addressing all deprecation warnings; and second, to the major release, with drop-in compatibility, modulo CHANGES. Here's the upgrade procedure under the above proposals, from version X.Y to X.Z: 1. Address all deprecation warnings against the currently used Lucene version (call it version X.Y[0]). 2. Upgrade to X.(++Y), addressing all deprecation warnings and checking CHANGES for exceptions to the back-compat policy, including mechanisms to maintain X.Y[0] defaults. 3. Iterate #2 until Y==Z. One consequence of these changes is that major version upgrades the same as minor version upgrades, with the exception that index format support (and default settings support?) will potentially require attention. Another consequence is that upgrade effort will no longer be amortizable. Currently, maintenance users can skip minor version upgrades with almost no penalty, and defer the upgrade pain to major release upgrades, since deprecation warnings can be safely ignored. (Not advocating this practice, just noting that it's possible.) Steve --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
