eclipse / xtext

Eclipse Xtext™ is a language development framework

Home Page:http://www.eclipse.org/Xtext

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Inconsistent major version change for org.eclipse.xtext.logging

ewillink opened this issue · comments

org.eclipse.xtext.logging has for a long time been version 1.x, but the latest 2.34 build changes it to 2.x which is superficially sensible given that all other xtext plugins are 2.x. However this is a violation of https://wiki.eclipse.org/Version_Numbering

If a breaking change is really required Xtext must go to 3.x, else please revert the common sense typo and stay at 1.x.

This is a bundle fragment and aligning the version simplified relent for is. Why are you affected by that change?

Note that the linked page has no section about fragments but a section about bundles without API which should be aligned with another bundle. Strictly speaking the change is in line with that document since the fragment was aligned with its containing feature

See https://ci.eclipse.org/ocl/job/ocl-master/864/console

[ERROR] You requested to install 'osgi.bundle; org.eclipse.xtext.logging [1.0.0,2.0.0)' but it could not be found

I've checked and can only find explicit 1.x dependencies in the auto-generated target files, so it appears that m2e / Tycho finds the dependency for me.

I did not update ref projects . Did Lorenzo do?

This version constraint should be widened to include 2.x: https://git.eclipse.org/r/plugins/gitiles/ocl/org.eclipse.ocl/+/refs/heads/master/releng/org.eclipse.ocl.releng.tycho/pom.xml#184

Yes. I missed this in my search. The problem is indeed presumably trivially fixed by changing the bound. (I'm not sure what your wizard comments are about.) Bad pom.xml is my 'bad'.

I don't really understand fragments; they just seem to be associated with pain. The guidelines do not seem to help/forbid.

But bottom line, it is really strange that a stable build, for Xtext still at 2.x, suddenly fails for a major version for xtext.logging without also failing for the top level Xtext versions. Is the major version change really necessary?

Note that the linked page has no section about fragments but a section about bundles without API which should be aligned with another bundle. Strictly speaking the change is in line with that document since the fragment was aligned with its containing feature

The need for a successful build to have an <extraRequirements> in pom.xml referencing the xtext.logging version arguably promotes the normally private import into an exported phenomenon for each plugin that requires the fragment. These are therefore aligned. A major change to xtext.logging needs a major change to most if not all xtext plugins and features. Of course if no major change is necessary, much better to avoid inflicting a spurious major change on users.

Sadness: https://github.com/xtext/xtext-reference-projects/actions/runs/7517431471/job/20463600774#step:4:7607
To be figured out

That version cannot be a Maven artifact version, but an OSGi one because Tycho will search for it in a p2 repository. It's better not specifying a version there, like we do for other extra requirements

This version constraint should be widened to include 2.x:
https://git.eclipse.org/r/plugins/gitiles/ocl/org.eclipse.ocl/+/refs/heads/master/releng/org.eclipse.ocl.releng.tycho/pom.xml#184

Yes. Changing to a 0.0.0 version bound seems appropriate since org.eclipse.xtext.logging does not conform to major version norms and surely only the correct version is available?

It's better not specifying a version there, like we do for other extra requirements

@LorenzoBettini Would you have the time to do this?

@szarnekow , yes, later today