On Oct 2, 2009, at 7:33 PM, Michael McCandless wrote:
Sigh. The introduction of new but deprecated methods is silly. Is there some simple automated way to catch/prevent these? The proliferation of ctors/factory methods is a nightmare.
Ah, so yet again, we are trying to work around a problem that is due to the ridiculousness of how we manage releases and deprecations and not necessarily something that is technically wrong. It's not like this is news. I've been complaining about the # of ctors for a long time (try training people on this stuff and you'll know what I mean). I'm not trying to be antagonistic, but if we would all just face facts that we do releases so few and far between that I just don't see it as being some massive hardship to remove some deprecations more often than every major release. It's funny, we add things in an agile way and everyone loves that, but we remove them in such a drawn out and monolithic manner that it is mind-boggling. We induce way more confusion than we prevent. Any sane programmer out there has to do more than just drop in any release, no matter what, (in other words, the whole drop in back compat thing is a myth, so get over it) and as soon as they start looking at the myriad of options, they are going to be confused. Far better for us just to remove an inferior method, with some smaller amount of warning, than to leave them guessing. Not only that, but as is evidenced by the new Token stuff, using deprecated and new stuff together may be even worse than just getting rid of the old stuff.
Simply put, I propose we adopt a model we've all discussed many times before where we mark deprecated items with the version they will be removed in, regardless of minor/major number, with the caveat that it must be at least one more minor version (i.e. announce deprecation in 2.4.0, remove in 2.5.0). Major versions than are about what we all expect out of major versions from every other software package in the land: major new features or near complete overhaul of existing functionality. With this model, we won't have massive amounts of deprecation piling up, our users are still given plenty of warning whereby they can _plan_ for it, and we have more flexibility in how we develop.
-Grant --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
