Bugzilla – Full Text Bug Listing
| Summary: | org.eclipse.xtext.ui 1.0.1 violates Eclipse API-policy | ||
|---|---|---|---|
| Product: | [Modeling] TMF | Reporter: | Alexander Nyßen <nyssen> |
| Component: | Xtext | Assignee: | Project Inbox <tmf.xtext-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | sven.efftinge |
| Version: | 1.0.1 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Alexander Nyßen
Xtext has a slightly different API strategy, because (so far) in Xtext everything is accessible which makes it very flexible but at the same time hard to change anything without changing (not breaking!) API. So we just distinguish between API breaking and non-breaking changes. We only introduced breaking changes between major versions and increment the minor and the service segment as it seems fit. What's the problem with the mentioned change? Well, if somebody develops against Xtext 1.0.1, he can create client code that does not work with 1.0.0 (in case of a newly introduced method, this will lead to a compilation problem). Eclipse's general API policy prevents this. So you don't have an actual problem but just wanted to point us to the guidelines, right? We knew them already and know that we don't fully implement them (they are guidelines, i.e. not mandatory). We discussed whether we want to use PDE's API tooling two years ago and decided to not do so, due to the different API philosophy we have in Xtext. The mentioned change wasn't made by accident, so PDE wouldn't have helped us in this particular case. (In reply to comment #3) > So you don't have an actual problem but just wanted to point us to the > guidelines, right? > We knew them already and know that we don't fully implement them (they are > guidelines, i.e. not mandatory). Correct. I ran into the reported compilation problem, but it's nothing I cannot live with, because I can update my target platform to 1.0.1. > > We discussed whether we want to use PDE's API tooling two years ago and decided > to not do so, due to the different API philosophy we have in Xtext. The > mentioned change wasn't made by accident, so PDE wouldn't have helped us in > this particular case. Why not stick to the API conventions concerning the versioning but rather allow to deliver API changes with the service release dates (if you don't want to postpone API changes to the next full year release cycle)? I would have preferred an Xtext 1.1.0 at the SR1 release date rather than an incompatible 1.0.1. So you mean never update the service level but always update the minor number? I think we increase the 'service' number for the 'service' releases because everybody else does so and the name suggests it (it might be written down somewhere). But you are right we should increase the minor number in future. Closing all bugs that were set to RESOLVED before Neon.0 Closing all bugs that were set to RESOLVED before Neon.0 |