lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Busch (JIRA)" <>
Subject [jira] Created: (LUCENE-1698) Change backwards-compatibility policy
Date Tue, 16 Jun 2009 16:15:07 GMT
Change backwards-compatibility policy

                 Key: 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

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 
   @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:
For additional commands, e-mail:

View raw message