On Jan 17, 2008, at 4:14 PM, Doug Cutting wrote:
Grant Ingersoll wrote:
1. We add a new section to CHANGES for each release, at the top
where we can declare what deprecations will be removed in the
_next_ release (major or minor) and also any interface API changes
2. When deprecating, the @deprecate tag should declare what version
it will be removed in and that version must be one greater than the
next targeted release. That is, if the next release is 2.4, then
anything deprecated in 2.3 is game to be removed in 2.9.
This would mean that one could never simply drop in the new jar and
expect things to still work, which is something that we currently
try to guarantee. That's a significant thing to give up, in terms
of usability. In my experience, folks hate incompatible changes,
since they're frequently no longer actively developing the portion
of the code that's broken, aren't seeking the new feature, etc.
This is why lots of folks stay back on old versions.
Yep. I agree. I don't make the suggestion lightly and a perfectly
valid answer is let's not bother. By the same token, do people
really just drop in a new release in these days of continuous
integration and short release cycles? At a minimum, it has to go
through a fair amount of testing, right?
An alternative is to do major releases more often, but, to some
extent, it's all just semantics. The key is communicating what the
exact changes are, regardless of what you call the version number.
This does bring an extra burden in that we would need to be better
about communicating upcoming changes. That I am not exactly thrilled
about, either.
In terms of benefits, this would permit us to evolve APIs more
rapidly. So it pits external usability against API evolution speed,
with no clear winner. +0
Yep, I am still on the fence, but wanted to revisit the discussion in
light of some recent bugs and comments about using Interfaces more.
Perhaps more important is how to handle fixing issues that change how
a document is indexed. Do we preserve the incorrectness for the sake
of back-compatibility? Or do we tell them this way is flat out wrong
and it won't be supported anymore?
-Grant
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
