Hi Sam,

Thanks for the below.

We discussed this thoroughly with Terence.

I understand your point, but:
 - this does not "break" compatibility, it simply alerts on potential breakage
 - with the growing number of targets, the above ability to loudly alert is required to allow enhancements at a different pace 
 - unfortunately, we cannot provide this guarantee i.e. we had to break compatibility simply to support Python, due to a bug with params not properly sent to the ST
 - I'm not sure this affects anyone. Since you would recompile to use the latest runtime, I believe extremely few people would have a problem in regenerating the code
 - I can only speak for myself, but I'm clearly not interested in spending time on backwards compatibility. If we need to change stuff to fix a bug, compatibility WILL be broken.

As mentioned, backwards compatibility is broken to fix a bug, required for Python. So we might be better stop offering a guarantee which we clearly can't provide.

Eric
 
Le 22 mai 2014 à 03:16, Sam Harwell <notifications@github.com> a écrit :

> In tool/resources/org/antlr/v4/tool/templates/codegen/Java/Java.stg:
> 
> > @@ -214,6 +222,8 @@ Parser(parser, funcs, atn, sempredFuncs, superClass) ::= <<
> >  Parser_(parser, funcs, atn, sempredFuncs, ctor, superClass) ::= <<
> >  @SuppressWarnings({"all", "warnings", "unchecked", "unused", "cast"})
> >  public class <parser.name> extends <superClass> {
> > +    static { RuntimeMetaData.checkVersion("<file.ANTLRVersion>"); }
> This breaks the compatibility guarantees we have been offering, where code generated and/or compiled against older versions of the Tool and Runtime may be executed with newer versions of the runtime, provided they do not use certain rare constructs which are documented in the release notes for each release (in a "Breaking Changes" section).
> 
> —
> Reply to this email directly or view it on GitHub.
>