> Because the version mechanism is not a single value for the entire library but rather feature by feature. I don't see how a global setter can help.
That's only true if we believe people use different Version values in different places of their code ... and note that they will still be able to. I'm not proposing to take out Version from the ctors, just to add an additional default-version the app can set and use.So if the app doesn't want to do it .. it doesn't have to. Shai On Tue, Apr 13, 2010 at 9:40 PM, DM Smith <dmsmith...@gmail.com> wrote: > I like the concept of version, but I'm concerned about it too. > > The current Version mechanism allows one to use more than one Version in > their code. Imagine that we are at 3.2 and one was unable to upgrade to a > most version for a particular feature. Let's also suppose that at 3.2 a new > feature was introduced and was taken advantage of. But at 3.5 that new > feature is versioned but one is unable to upgrade for it, too. Now what? Use > 3.0 for the one feature and 3.2 for the other? > > What about the interoperability of versioned features? Does a version 3.0 > class play well with a 3.2 versioned class? How do we test that? > > A long term issue is that of bw compat for the version itself. The bw > compat contract is two fold: API and index. The API has a shorter lifetime > of compatibility than that of an index. How does one deprecate a particular > version for the api but not the index? How does one know whether one > versioned feature impacts the index and an other does not? > > I'm hoping that I'm imagining a problem that will never actually arise. > > Shai, to your suggestion: Because the version mechanism is not a single > value for the entire library but rather feature by feature. I don't see how > a global setter can help. > > -- DM > > > On 04/13/2010 11:27 AM, Shai Erera wrote: > >> Hi >> >> I'd like to propose a relaxation on the Version API. Uwe, please read the >> entire email before you reply :). >> >> I was thinking, following a question on the user list, that the >> Version-based API may not be very intuitive to users, especially those who >> don't care about versioning, as well as very inconvenient. So there are two >> issues here: >> 1) How should one use Version smartly so that he keeps backwards >> compatibility. I think we all know the answer, but a Wiki page with some >> "best practices" tips would really help users use it. >> 2) How can one write sane code, which doesn't pass versions all over the >> place if: (1) he doesn't care about versions, or (2) he cares, and sets the >> Version to the same value in his app, in all places. >> >> Also, I think that today we offer a flexibility to users, to set different >> Versions on different objects in the life span of their application - which >> is a good flexibility but can also lead people to shoot themselves in the >> legs if they're not careful -- e.g. upgrading Version across their app, but >> failing to do so for one or two places ... >> >> So the change I'd like to propose is to mostly alleviate (2) and better >> protect users - I DO NOT PROPOSE TO GET RID OF Version :). >> >> I was thinking that we can add on Version a DEFAULT version, which the >> caller can set. So Version.setDefault and Version.getDefault will be added, >> as static members (more on the static-ness of it later). We then change the >> API which requires Version to also expose an API which doesn't require it, >> and that API will call Version.getDefault(). People can use it if they want >> to ... >> >> Few points: >> 1) As a default DEFAULT Version is controversial, I don't want to propose >> it, even though I think Lucene can define the DEFAULT to be the latest. >> Instead, I propose that Version.getDefault throw a >> DefaultVersionNotSetException if it wasn't set, while an API which relies on >> the default Version is called (I don't want to return null, not sure how >> safe it is). >> 2) That DEFAULT Version is static, which means it will affect all indexing >> code running inside the JVM. Which is fine: >> 2.1) Perhaps all the indexing code should use the same Version >> 2.2) If you know that's not the case, then pass Version to the API which >> requires it - you cannot use the 'default Version' API -- nothing changes >> for you. >> One case is missing -- you might not know if your code is the only >> indexing code which runs in the JVM ... I don't have a solution to that, but >> I think it'll be revealed pretty quickly, and you can change your code then >> ... >> >> So to summarize - the current Version API will remain and people can still >> use it. The DEFAULT Version API is meant for convenience for those who don't >> want to pass Version everywhere, for the reasons I outlined above. This will >> also clean our test code significantly, as the tests will set the DEFAULT >> version to TEST_VERSION_CURRENT at start ... >> >> The changes to the Version class will be very simple. >> >> If people think that's acceptable, I can open an issue and work on it. >> >> Shai >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > >
