Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-papyrus.dev] Important: Version Management Changes
Hi Christian

Sorry, I forgot to reply before; your more recent email prompted me to explain what has been good/bad with OCL versions.

I must caution against changing versions only when strictly necessary.

OCL has made mistakes in both directions.

When UML2 changed to 2.x, only ocl.uml plugins changed to 2.x, leaving ocl.ecore plugins at 1.x in a 2.x feature

When UML2 changed to 3.x, the inconsistency was considered wrong and all plugins and features changed to 3.x.

When UML2 changed to 4.x, only ocl.uml changed to 4.x, leaving ocl.ecore at 3.x in a 4.x feature

When UML2 changed to 5.x, only ocl.uml changed to 5.x, leaving ocl.ecore at 3.x in a 5.x feature
(at this point the UML2 re-exports were removed so that a UML2 change to 6.x does not now mandate an ocl.uml change to 6.x)

When the pivot was promoted from examples it became 1.x, ocl.uml stayed at 5.x, ocl.ecore stayed at 3.x all in a 6.x feature.

Consequently a user can legitimately claim to be using OCL 1.x, 3.x, 5.x, 6.x (or of course OMG's 2.x). It's all very confusing for users and developers alike. And that is just the major versions.

The most major mistake was changing ocl.ecore from 1.x to 3.x, which caused pain for EMFq at least. There was no actual need. I think we could still be on ocl.ecore 1.x. A better understanding of the guidelines could have avoided this.

The next major mistake was re-exporting the UML2 plugins. Only re-export plugins that are so fundamental that a major version change must ripple; i.e. for Papyrus: platform and EMF. Possibly not GEF or UML2. Certainly not OCL / EMFv / EMFq / EMFt / EMFc.

Applying the guidelines at the component level, i.e. ocl.ecore / ocl.uml / ocl.pivot makes sense since components may be re-used independently. Applying the guidelines at the plugin level makes no sense; there is just no way that plugins in a component can be re-used piecemeal. So I strongly recommend that the same plugin version is used throughout each independently re-useable component. NB if you have a papyrus.common that everything uses then you only have one component, since the 'common' always gets just one new useful facility that then infects everything else.

Papyrus is much more a useful system rather than many subsystems, so providing fine-grained re-useability seems misguided.

For the last couple of years I have pursued the following policy.

Add 0.0.100 to all plugin / feature versions the day after a release. This is in the guidelines by implication but too often ignored in practice. It is necessary to avoid the too regular accident that a maintenance build occludes a development build in a composite repo.

During development, perhaps aided by OOMPH, advance the minor version for any changed plugin with a x.x.y00 version.

    Regards

        Ed Willink

On 25/02/2016 03:20, Christian Damus wrote:

Hello, Team,

Now that we have been putting so much effort into the refactoring of APIs, it has been decided by the project leadership that as of the Neon Release, Papyrus will be adhering to the Eclipse Guidelines for Version Numbering [1].

Accordingly, we will no longer be bulk updating the versions of all bundles and features with every release. Instead, version numbers will evolve individually according to the nature of their changes, in API and behaviour. All bundles and features had already been bulk updated to version 1.2.0 earlier in the Neon development stream; these are unchanged except where versions are updated to 2.0.0 to reflect API breakage from refactorings and other changes.

Project Configuration Changes

Changes have been merged into the master branch for the Main and Developer plug-ins to help us keep rigorous control over our versions:

  • all projects are configured with the PDE API Tooling builder. This flags various problems in versioning, such as a bundle version that needs to be changed, missing @since Javadoc tags for new APIs, etc. This does require developers to point the tooling at a baseline of the previous Papyrus version for comparison. This is as simple as, for example, configuring your Neon workspace to use a Mars installation of Papyrus as the baseline

  • all projects are also configured with the Oomph Version Management builder. This performs additional version validation that PDE does not, for example consistency of feature versions with contained bundle versions, consistency of POM versions with their corresponding plug-in/feature manifests, and more. For those that use the Papyrus Setup model to provision their environments, the requisite tools will be installed for you. Otherwise, you will get none of this Oomph goodness (you won’t see any change in PDE/JDT behaviour)

  • the Developer Tools menu actions that bulk update versions of Papyrus plug-ins and features, as well as bundle dependency version, are removed.

  • new actions are added in the Developer Tools to assist in maintaining clean bundle dependencies:
    • in the Plug-in Tools context menu for plug-in projects and MANIFEST.MF files
      • an Update Dependency Ranges action that sets all bundle dependencies to have version ranges compatible with the current version of each dependency in the workspace or PDE Target. Certain bundles are excluded that are known not to follow Eclipse’s semantic versioning, such as Guava and ICU4J
      • an Optimize Bundle Dependencies action that computes the minimal bundle dependencies that need to be re-exported to cover imported APIs that are exposed by the bundle’s own exported API
    • in the ibis-head menu in the main menu bar, a Synchronize POM Versions menu that ensures all plug-in and feature projects have version numbers in the POM to match the version number in the Eclipse manifest

Tests Changes

A few of the JUnit tests in the BundleTests class are removed because they are no longer appropriate:

  • versionTest — bundle versions now evolve organically for each bundle
  • papyrusDependencyVersionTest — all Papyrus bundles no longer have the same version
  • reexportDependencies — re-exports are now employed where necessary to export a bundle’s complete API

Documentation Changes

Some of our procedural documentation in the Wiki is updated to reflect these changes:

If there’s any other documentation that needs updating, please let me know or, better, just edit it. 😀

Build Changes

Note that the build system is not yet updated to integrate version validation via PDE API Tools and Oomph, but this is in the plan. So, for now, we are relying on developers using these tools in their workbenches to ensure consistency before pushing changes to the central repository.

Thanks,

Christian


  1. https://wiki.eclipse.org/Version_Numbering  ↩

  2. https://wiki.eclipse.org/index.php?title=Papyrus/Code_Standards  ↩

  3. https://wiki.eclipse.org/index.php?title=Papyrus_Developer_Guide/Build_Process:_How_To  ↩



_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev

Back to the top