lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Miller (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-1698) Change backwards-compatibility policy
Date Thu, 02 Jul 2009 18:03:47 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-1698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12726590#action_12726590
] 

Mark Miller commented on LUCENE-1698:
-------------------------------------

I agree. I think we have the tools we need, we just need to accelerate our releases if we
want to deprecate faster. We could have made 2.4 2.9. We could have released faster with fewer
issues.

I also think that its confusing that you could drop in 4.2 over 4.1, but try 4.4 and your
out of luck. Major number bumps and nice and intuitive.

I was behind a change in back compat (though I had no idea what change - was waiting for the
right one ;) ), basically for the case of defaults for new users - out of the box performance/experience.
The version stuff Mike came up with appears to fix that rather nicely without tweaking back
compat versioning schemes though. We can just jump numbers faster.

> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message