lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Busch (JIRA)" <>
Subject [jira] Commented: (LUCENE-1698) Change backwards-compatibility policy
Date Mon, 05 Oct 2009 19:47:31 GMT


Michael Busch commented on LUCENE-1698:

Now that 2.9 is out and 3.0 is close, I'd like to get back to this one to get to a conclusion.

We had several informal +1s on javadev and a -0 here from Hoss and Mark. So no -1 yet.

I think the final decision should be made with an official vote on java-dev. How does everyone
feel about this? Shall we have a vote right away? I think it might be a good idea to get some
feedback about this proposal on java-user first? Or we could even wait a month and bring it
up in Oakland at the Lucene BOF?

> Change backwards-compatibility policy
> -------------------------------------
>                 Key: LUCENE-1698
>                 URL:
>             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
> 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