I guess I am suggesting that instead of maintaining the whole major/
minor thing (not including file format) that we relax a bit and say
that any give feature we choose to remove or add has to go through two
release cycles, which according to your averages, would equal just
over 1 year's time. If people can't adapt to a coming change that was
announced a year ago, then I have to wonder why they need to upgrade
at all. (OK, that is a little strong, but...)
And mind you, I am not set in stone about this, I'm just starting the
conversation, being a bit of a devils advocate. I would like to know
if there is a way we can retain Lucene's solid stability and maturity
and encourage new and better features and not have to maintain so much
deprecated code.
I especially think this shorter cycle is useful when it comes to
deprecated features (not that there is much difference between
removing methods and adding methods.) Basically, we have code in
Lucene that we all agree should not be used, yet we leave it sitting
in there for, on average 2 years or more. Dropping that to be 1 year,
on average, is not going to all of a sudden break everyone and make
Lucene unstable. Besides, if people like the deprecated methods so
much, why upgrade in the first place? No one is forcing them.
Usually, the answer is there is some new feature somewhere else that
is needed, but that just shows that people are willing to invest the
time to get better features in the first place. Besides, just because
we can remove things, doesn't mean we have to remove them. For
instance, some bigger features that we improve, we may want to
deprecate for more than one full release cycle.
Fieldable is, in my mind a prime example of needing the ability to
announce additions. Let's say we come up with some new-fangled Field
type called Magic. This thing is so beautiful we all wonder how we
ever lived without it. Great. Now all we need to do is add an
isMagic() declaration onto Fieldable and we're good. Oops, can't do
that. Gotta wait 2 more years for 4.0. Seriously, we have to be
locked into an interface for 2 years or more? And oh by the way, in
that 2 years, Lucene has been left in the dust b/c every other open
source search engine out there already has Magic capabilities.
Furthermore, that gives us one 6 month window (+/-) to get it right
for the next 2 years. I know, it's a bit over the top, but I think it
demonstrates the point. I also don't see what is unstable about
telling the community, well in advance, that the following API changes
are coming, please plan accordingly. Most projects out there don't
even do that. Seriously, in Maven you get updates to functionality
without even knowing you are getting them and I am no where near
advocating for that.
And again, I still think the more pertinent issue that needs to be
addressed is how to better handle bugs in things like Tokenization,
etc. where people may have dependencies on broken functionality, but
haven't fully comprehended that they have such a dependency. I don't
think those fixes/deprecations should have to wait for a major release.
Does anyone have experience w/ how other open source projects deal
with this? Do they have explicit policies? Is it ad hoc? I know for
instance, in a certain library I was using that the difference between
what was announced as a beta and as 1.0 was quite different. Granted,
one could expect that a bit more out of something that was going from
0.X to 1.0, but still it was a pretty significant, more or less
unannounced change (unless you count following all the commit messages
as announcement) and it will require a decent amount of work to upgrade.
-Grant
On Jan 17, 2008, at 6:58 PM, Steven A Rowe wrote:
Hi Grant,
On 01/17/2008 at 7:51 AM, Grant Ingersoll wrote:
Our minor release cycles are currently in the 3-6 months range
and our major release cycles are in the 1-1.5 year range.
Since 2.0.0, including 2.3.0 - assuming it will be released in the
next week or so - the minor release intervals will have averaged
about 6.5 months, over three releases.
Historically, the major release cycle intervals have roughly been:
1.0 - 6 months (March 2000 - October 2000)
2.0.0 - 6 years (October 2000 - May 2006)
Six years is an incredibly long time to maintain backward
compatibility.
Assuming there will be a 2.4 release, and then 3.0 following it,
it's pretty optimistic (IMHO) to think that it will be released
before June 2008, so for 3.0, that would be:
3.0.0 - 2 years (May 2006 - May 2008)
Two years doesn't seem so long in comparison :).
I think giving someone 4-8 (or whatever) months is more than
enough time to prepare for API changes. I am not sure how
this would effect Index changes, but I do think we should
KEEP our current index reading policy where possible. This
may mean that some deprecated items cannot be removed until
a major release and I think that is fine.
Given the 6.5 month average minor release interval for the most
recent major release, and the relatively low probability that this
will shrink appreciably, you seem in essense to be advocating
altogether abandoning backward API compatibility from one (minor)
release to the next.
However, below you are advocating a minimum of one "test balloon"
release between incompatible changes:
On 01/17/2008 at 3:41 PM, Grant Ingersoll wrote:
[N]o interface/deprecation changes would be done without announcing
it
and there being at least one release in the meantime. Thus, if we
wanted to add isFancySchmancy() onto Fieldable today, it would have
to
be announced, patch provided and referenced, a release without it
(i.e.
2.3) and then it would be available in 2.4. By ad-hoc, I meant
that we
wouldn't just announce it and then have it show up in 2.3 and not
give
people time to digest it.
If I understand you correctly, a major release series could contain
a whole series of non-aligned overlapping back-incompatible changes,
since you are allowing individual features to alter backward
incompatibility independently of other features. I think this is
actually worse than just abandoning back-compatibility, since users
would have to look up information on each individual feature to be
able to figure out whether they can do a drop-in upgrade.
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------
Grant Ingersoll
http://lucene.grantingersoll.com
http://www.lucenebootcamp.com
Lucene Helpful Hints:
http://wiki.apache.org/lucene-java/BasicsOfPerformance
http://wiki.apache.org/lucene-java/LuceneFAQ
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
