Release 4.4.0: November 16, 2015

[GerardPaligot]

Hi all,

The next release 4.4.0 is planned for Monday 16th November.

You can find the temporary changelog below:

Minor API Changes

• Throws a SpoonException when a processor is not found: feat: Throws a SpoonException when the processor is not found. #366
• Deprecates process(List) method in SpoonModelBuilder for a new one: refactor(api): Deprecates process method for a new one. #402
• Removed deprecated secondary methods: cleans the API of the internal interface ProcessingManager #370, Removes all deprecated arguments in the Launcher. #358, Updates version of spoon in doc and removes all deprecated code #343

Documentation

• New documentation:
  • Getting started (http://spoon.gforge.inria.fr/): doc: #322 Getting Started tutorial in the spoon website. #342
  • Usage (http://spoon.gforge.inria.fr/command_line.html): doc: #322 Usage tutorial in the spoon website. #344
  • Spoon Meta Model (http://spoon.gforge.inria.fr/structural_elements.html): doc: #322 Spoon meta model tutorial in the spoon website. #351
  • Quering source code elements (http://spoon.gforge.inria.fr/filter.html): doc: #322 Quering source code elements tutorial in the spoon website. #352
  • Processing source code elements (http://spoon.gforge.inria.fr/processor.html): doc: #322 Processing source code elements in the spoon website. #357
  • Templating source code (http://spoon.gforge.inria.fr/template_definition.html): doc: #322 Templating source code in the spoon website. #360
• Documentation put in the master branch in the repo: doc: #322 Creates a new website for the future documentation! #331

Fixes

• Prints the parent class when it has generics: Print the full qualified name of the variable type when the parent of the type has generics #389
• Fix method calls on annotation: Fix method calls on annotations #388
• Missing CtTypeReference for instanceof expressions when querying: Missing CtTypeReference for instanceof expressions when querying. #392
• Writes correctly field access in anonymous type: fix(access): Writes correctly field access in anonymous type. #387
• Handles unicode characters in string literals: Handles unicode characters in string literals #382
• CtTypeParameterReference doesn't print always full generic: fix: CtTypeParameterReference doesn't print always full generic. #381
• Allows enum without fields: fix: Writes always ";" in an enum for their fields. #380
• Removes array notation in a lambda parameter and diamond operator: Fix implicit array in diamond operator and lambda parameter. #379
• Writes parameters in a lambda expression without their types if the original code didn't write them: fix(lambda): Creates implicit type for primitive types. #384
• Sets the parent when we used insertAfter and insertBefore methods: Sets the parent in insertBefore/After and refactors these methods. #375
• Fixes a bug with circular references in generic types: fix: Circular references with generic types. #374
• Fix CtClass.getConstructor with Array parameter: Fix anonymous classname and CtClass.getConstructor #373
• Better handles invocations in noclasspath mode: fix(noclasspath): handles invocations in noclasspath mode. #350

CI

• Integrates AppVeyor. AppVeyor is an alternative to Travis but in a Windows environment: test(windows): Fixes a test case on Windows. #394
• Integrates INRIA Jenkins and Github (http://ci.inria.fr/sos)

[swolf91]

Correct me if I'm wrong, but you removed deprecated api 894a2e7. so shouldn't it be version 5.0.0 according to the conversation in #203 ?

[GerardPaligot]

Not exactly. A major version means incompatible API changes and a minor version means minor API changes but between each version (major or minor), we remove all deprecated methods (see Checklist).

[pschichtel]

Well removing deprecated API is an API breaking change, which conflicts with the minor update convention of staying API compatible. Minor version can change API in non-breaking ways (adding API, deprecating API, but removing methods is definitly breaking. So either stick with the convention or prominently document that minor updates can break things. You could document the removal version in the javadoc of the depreceted method/class.

Addition: A release process checklist is not a good place to document this

[swolf91]

@GerardPaligot I see it like @pschichtel.
Also you wrote about it in issue #203.
@pschichtel wrote:

The important part about the minor version (Y): API compatibility. So adding new APIs and changing implementations is fine, but the existing API should stay compatible. You can however deprecate APIs and schedule them for removal.

and @monperrus answered:

Yes, this is what we do.

[monperrus]

I see your point.

API compatibility is both syntactic (does it compile?) and behavioral (does it execute as before?).

To this extent, even a bug fix may "break" existing code, this is the classical story of code exploiting a bug (it's not a bug, it's a feature).

So my view is that "API breaking" is not binary (it's not only syntactic, it's not only bug fix vs removal), and the difference between a major and minor is the result of a qualified, well thought decision.

that said, let's be very concrete: the removed methods seem to be secondary to us and only deserve a minor version.

Are there any removed method on which you rely on, for which the deprecation period was too short?

[pschichtel]

My point was: stick to the convention (minor will not break API consumers) or make it explicit through prominent documentation.
"Changes in API" doesn't even mention that API was removed

[monperrus]

You're right, we will improve the doc.

--Martin

[GerardPaligot]

Spoon 4.4.0 is published and on the way for Maven Central!

I close this issue.