[ https://issues.apache.org/jira/browse/LUCENE-1698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778262#action_12778262 ]
Uwe Schindler commented on LUCENE-1698: --------------------------------------- This is the last issue blocking 3.0 somehow. Should I remove the fix version, or do we already have some "official" backwards document available somewhere to resolve this? > Change backwards-compatibility policy > ------------------------------------- > > Key: LUCENE-1698 > URL: https://issues.apache.org/jira/browse/LUCENE-1698 > Project: Lucene - Java > Issue Type: Task > Reporter: Michael Busch > Assignee: Michael Busch > Priority: Minor > Fix For: 3.0 > > > These proposed changes might still change slightly: > I'll call X.Y -> X+1.0 a 'major release', X.Y -> X.Y+1 a > 'minor release' and X.Y.Z -> X.Y.Z+1 a 'bugfix release'. (we can later > use different names; just for convenience here...) > 1. The file format backwards-compatiblity policy will remain unchanged; > i.e. Lucene X.Y supports reading all indexes written with Lucene > X-1.Y. That means Lucene 4.0 will not have to be able to read 2.x > indexes. > 2. Deprecated public and protected APIs can be removed if they have > been released in at least one major or minor release. E.g. an 3.1 > API can be released as deprecated in 3.2 and removed in 3.3 or 4.0 > (if 4.0 comes after 3.2). > 3. No public or protected APIs are changed in a bugfix release; except > if a severe bug can't be changed otherwise. > 4. Each release will have release notes with a new section > "Incompatible changes", which lists, as the names says, all changes that > break backwards compatibility. The list should also have information > about how to convert to the new API. I think the eclipse releases > have such a release notes section. Furthermore, the Deprecation tag > comment will state the minimum version when this API is to be removed, > e.g. > @deprecated See #fooBar(). Will be removed in 3.3 > or > @deprecated See #fooBar(). Will be removed in 3.3 or later. > I'd suggest to treat a runtime change like an API change (unless it's fixing > a bug of course), > i.e. giving a warning, providing a switch, switching the default behavior > only after a major > or minor release was around that had the warning/switch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org