Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of jak-commons-dev@m.gmane.org
 designates 80.91.229.12 as permitted sender)
Mail-Followup-To: dev@commons.apache.org
To: dev@commons.apache.org
From: =?UTF-8?B?SsO2cmc=?= Schaible <joerg.schaible@gmx.de>
Subject: Re: [JEXL] [PreVOTE] OK to release Jexl with some Clirr errors but no
 package/id change?
Followup-To: gmane.comp.jakarta.commons.devel
Date: Mon, 05 Dec 2011 23:21:42 +0100
Lines: 74
Message-ID: <jbjg5m$r93$3@dough.gmane.org>
References: 
 <CAOGo0VYT=JTCC0tfn-hxvQx9xsdh6fnzCfmTxMhiaSQ1jC6bBw@mail.gmail.com>
Reply-To: joerg.schaible@gmx.de
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7Bit
Mail-Copies-To: nobody
User-Agent: KNode/4.4.11

Go for 2.1.

The problem of binary incompatibility only arise if you do *not* have access 
to the sources.

sebb wrote:

> The Jexl 2.0 branch now has only a few incompatibilities reported by
> Clirr (see below).
> 
> Also the 2.0.1 JUnit tests now run (with minor essential changes)
> against both 2.0.1 and 2.1-SNAPSHOT.
> 
> The remaining errors all relate to adding methods to interfaces.
> According to the JLS [1], adding methods to an interface does not
> break *binary* compatibility; however of course it will break source
> compatibility.
> I assume that Clirr has got this wrong; or is failing to distinguish
> source compatibility from binary compatibility.
> There is a test case to show this -
> ScriptTest.testScriptInterfaceBinaryCompat() - in the
> COMMONS_JEXL_2_0_1_TEST branch.
> 
> I think it would be OK to release the code without changing package
> names / Maven id if other Commons developers agree.
> What do others think?
> 
> Assuming that there are no objections, there is the question of what
> version to use.
> 
> The changes clearly require at least a minor version bump, i.e. 2.1
> rather than 2.0.2.
> It is unlikely that any users will have implemented the Script
> interface directly; any that have done so will need to update their
> source before recompiling.
> Does such a source incompatibility require a major version bump to 3.0?
> [Note: this does *not* mean a package change is required; however a
> package change would require a major version bump]
> 
> I think this discussion is best held separately from any release vote,
> as there are always plenty of other items to check in a release
> vote...
> 
> =====
> 
> ERROR: 7012: org.apache.commons.jexl2.introspection.Uberspect: Method
> 'public org.apache.commons.jexl2.introspection.JexlMethod
> getConstructorMethod(java.lang.Object, java.lang.Object[],
> org.apache.commons.jexl2.JexlInfo)' has been added to an interface
> ERROR: 7012: org.apache.commons.jexl2.JexlInfo: Method 'public
> org.apache.commons.jexl2.DebugInfo debugInfo()' has been added to an
> interface
> ERROR: 7012: org.apache.commons.jexl2.Script: Method 'public
> java.lang.Object execute(org.apache.commons.jexl2.JexlContext,
> java.lang.Object[])' has been added to an interface
> ERROR: 7012: org.apache.commons.jexl2.Script: Method 'public
> java.lang.String[] getLocalVariables()' has been added to an interface
> ERROR: 7012: org.apache.commons.jexl2.Script: Method 'public
> java.lang.String[] getParameters()' has been added to an interface
> ERROR: 7012: org.apache.commons.jexl2.Script: Method 'public
> java.util.concurrent.Callable
> callable(org.apache.commons.jexl2.JexlContext)' has been added to an
> interface
> ERROR: 7012: org.apache.commons.jexl2.Script: Method 'public
> java.util.concurrent.Callable
> callable(org.apache.commons.jexl2.JexlContext, java.lang.Object[])'
> has been added to an interface
> ERROR: 7012: org.apache.commons.jexl2.Script: Method 'public
> java.util.Set getVariables()' has been added to an interface
> 
> [1]
> 
[http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html#45347


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org