Bugzilla – Full Text Bug Listing
| Summary: | Bump version numbers for Sirius 3.0 | ||
|---|---|---|---|
| Product: | [Modeling] Sirius | Reporter: | Pierre-Charles David <pierre-charles.david> |
| Component: | Releng | Assignee: | Cedric Brun <cedric.brun> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | belqassim.djafer, laurent.redor |
| Version: | 2.0.0 | Keywords: | triaged |
| Target Milestone: | 3.0.0M5 | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: |
https://git.eclipse.org/r/42304 https://git.eclipse.org/r/42411 https://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=ee87457ff8908b57718b4584c981466a23da2402 |
||
| Whiteboard: | |||
|
Description
Pierre-Charles David
Here is the result of applying semantic versioning through the 'baseliner' prototype: https://git.eclipse.org/r/#/c/40540/1 As the end-result we expects from applying the semantic versioning is the capacity for the specifier to express its dependencies at the package level so that the tooling notify him with no 'false positives' I did try with EcoreTools. I changed all the require-bundles into import-packages with version=[2.0,3.0), "simulating" my will to support both Sirius 2.0 and Sirius 3.0 with the same codebase. Here are the problematic packages which I'm using which 'upgraded to 3.0' org.eclipse.sirius.business.api.session;version="[2.0.0,3.0.0)", org.eclipse.sirius.ecore.extender.business.api.accessor;version="[2.0.0,3.0.0)", org.eclipse.sirius.ecore.extender.business.api.accessor.exception;version="[2.0.0,3.0.0)", org.eclipse.sirius.ui.business.api.dialect;version="[2.0.0,3.0.0)", org.eclipse.sirius.viewpoint;version="[2.0.0,3.0.0)", org.eclipse.sirius.viewpoint.provider;version="[2.0.0,3.0.0)" Total number of imported packages is 37. All of these incompatibilities are matching actual changes into those APIs which have been introduced quite recently (which one can check quite easily looking at the api_change file generated by the baseliner) as a further comment : changing the version into "[2.0.0,3.0.0]" for the upgraded packages makes the compiler happy. EcoreTools (master) builds just fine with the same code with 2.x and 3.x (source compatibility) Here is how I see it during the 3.0 release cycle : * features should be bumped at 3.0.0 * bundle version could be a°) either semanticaly managed b°) bumped to 3.0 anyway I would pick b°) for this release, the tooling to maintain the semvers has not been adopted in the team yet (its just not ready for prime time at a "team scale") and doing it "after the change" has little sense, we'll end up with 3.0 bundles fairly quickly anyway. On the other hand by numbering the exported packages with the semantic version we can start experimenting from a consummer point of view, and from a developper point of view and raising awareness, within the team, of what changes caused this bump. We could also take this chance to, maybe, move some classes out of some package we consider "the core API you can rely on" so that further changes on those don't break the compatibility. What do you think ? (In reply to Cedric Brun from comment #4) > Here is how I see it during the 3.0 release cycle : > > * features should be bumped at 3.0.0 > * bundle version could be > a°) either semanticaly managed > b°) bumped to 3.0 anyway > > I would pick b°) for this release, the tooling to maintain the semvers has > not been adopted in the team yet (its just not ready for prime time at a > "team scale") and doing it "after the change" has little sense, we'll end up > with 3.0 bundles fairly quickly anyway. Agreed. > On the other hand by numbering the exported packages with the semantic > version we can start experimenting from a consummer point of view, and from > a developper point of view and raising awareness, within the team, of what > changes caused this bump. We could also take this chance to, maybe, move > some classes out of some package we consider "the core API you can rely on" > so that further changes on those don't break the compatibility. > > What do you think ? It sounds fine to me. Identifying more clearly what is "the core API you can rely on" also intersects with bug #422449 "Document the Sirius compatibility and migration policy". See in particular https://bugs.eclipse.org/bugs/show_bug.cgi?id=422449#c4 I just merged Cédric's patches, with the baseliner configuration files and the semantic bump for the exported pacakges. For the bundles and features themselves, I simply bumped everything to 3.0.0. Done. New Gerrit change created: https://git.eclipse.org/r/42304 WARNING: this patchset contains 2741 new lines of code and may require a Contribution Questionnaire (CQ) if the author is not a committer on the project. Please see:https://wiki.eclipse.org/Project_Management_Infrastructure/Creating_A_Contribution_Questionnaire New Gerrit change created: https://git.eclipse.org/r/42411 WARNING: this patchset contains 7684 new lines of code and may require a Contribution Questionnaire (CQ) if the author is not a committer on the project. Please see:https://wiki.eclipse.org/Project_Management_Infrastructure/Creating_A_Contribution_Questionnaire Gerrit change https://git.eclipse.org/r/42304 was merged to [master]. Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=ee87457ff8908b57718b4584c981466a23da2402 Verified as technical issue Available in Sirius 3.0.0. See https://wiki.eclipse.org/Sirius/3.0.0. |