Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [m2e-dev] semantic versioning / Re: Starting a 2.0 with breaking changes soon? 
m2e already uses semantic versioning at artifact level.
not really, we just "bump to current release version", also "artifact level" is way to broad to be really useful. In fact the artifact version should be the maximum version of all export-package versions. 


I believe connectors compatibility can already be defined with the
Import-Package/Require-Bundle version range restriction.
probably yes, but it seems it is not used anywhere. We should also strictly discourage using require-bundle as it hinder us to move code around. 


The m2e release version that appears on tag and PMI has no
technical meaning, it more a "marketing" version.
We should clearly state then that this "release-version" has nothing to do with the bundle/package version. 


We kind of already have this with exported non-internal packages.
"exported non-internal packages" are a real strange thing, we should not use that as this is complete eclipse specific. 


What do you call semver actually?
semver is an official specification that could apply to not only eclipse see: 

- https://semver.org/
- https://github.com/semver/semver
- https://enroute.osgi.org/FAQ/210-semantic_versioning.html



The reference for Eclipse world
Sure Eclipse always has had its own "standards", but here I'm referencing to what most developers understand when using the term semantic versioning :-) 


Am 17.02.22 um 10:50 schrieb Mickael Istria:
On Thu, Feb 17, 2022 at 7:07 AM Christoph Läubrich <laeubi@xxxxxxxxxxxxxx <mailto:laeubi@xxxxxxxxxxxxxx>> wrote: 

    What I'm wondering (now we are ready for breaking things)  is if we are
should switch from release/bump versions to semantic versioning 

m2e already uses semantic versioning at artifact level.

    1) currently the concept of "compatible connectors" is broken and
    effectively does not work. with semver there would be a natural
    definition of "compatible" but we might require connectors to update
    from time to time their version ranges.
I believe connectors compatibility can already be defined with the Import-Package/Require-Bundle version range restriction. 

    2) we never need to think about if API breaks are good, or need a 3.0
    for m2e as a whole, and will get a better feeling if and how we break
    consumers.
We're already free to break API and change the bundle versions accordingly. The m2e release version that appears on tag and PMI has no technical meaning, it more a "marketing" version. 

    m2e.api -> contains all API / SPI interfaces with versioned packages
    m2e.core -> contains our implementations of the above and so on, should
    never be referenced by clients or only in rare circumstances
    m2e.ui -> all the UI stuff.


We kind of already have this with exported non-internal packages.

    Beside that I planned to add semver support to tycho as well, so
    even if
    we for a short time have to handle this manually we hopefully will get
    good automatic support for this soon through tycho, adding such support
    would be best if there is at least one consumer (m2e in this case).
What do you call semver actually? The reference for Eclipse world is https://wiki.eclipse.org/Version_Numbering <https://wiki.eclipse.org/Version_Numbering> and that's what is currently applied and what Tycho+PDE API Tools are capable of dealing with as it's done on Eclipse Platform. 

_______________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/m2e-dev

Back to the top