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? 
> OSGi misses an important point about "internal APIs"
There is no such thing as "internal API", you either export a package than it is visible to others or not.
> Or maybe there is some other mechanism I've been missing to cover that case?
requiring such a construct is more often an indication that your API/Bundle is not well shaped. "Internal API" is just the eclipse term of "its useful but I don't want to maintain backward compatibility here" that's a complete different story.
In a well shaped system there is no need for such constructs as everything that is internal is simply never exported. 

> Seems like the Eclipse recommandations are very close to
So why not switching then to the more broad adopted terms then? Semver is not only a matter of package export but also proper version imports and eclipse is simply not respect that part of semver .. 

Am 17.02.22 um 11:22 schrieb Mickael Istria:
On Thu, Feb 17, 2022 at 11:05 AM Christoph Läubrich <laeubi@xxxxxxxxxxxxxx <mailto:laeubi@xxxxxxxxxxxxxx>> wrote: 

    not really, we just "bump to current release version", also "artifact
    level" is way to broad to be really useful.
No, some people do that. But it's not a requirement nor what's preferred. I personally always increase the micro segment only whenever possible. However, bumping by +0.0.1 or +0.0.N doesn't make a difference in practice, that why both approaches are tolerated in m2e. What need to be avoided is bumping by +0.1.0 where +0.0.N would be sufficient. 

    In fact the artifact version
    should be the maximum version of all export-package versions.


Major and minor yes, micro no.

    probably yes, but it seems it is not used anywhere.
People don't using a standard solution is rarely resolved by building another custom solution, It just mean the people don't care about this problem enough to try mitigate it. It's a behavioral problem (usually not important enough to be worrying) of consumer, not a technical limitation causing that. 

    We should also
    strictly discourage using require-bundle as it hinder us to move code
    around.
Right, but it's not m2e's fight. I think it's more PDE's duty to lead towards that good practice. you may want to revive https://bugs.eclipse.org/bugs/show_bug.cgi?id=284731 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=284731> to achieve that goal. 

    We should clearly state then that this "release-version" has nothing to
    do with the bundle/package version.
Right. Any idea where this could fit (ie where would that target audience stumble upon this info)? 

    "exported non-internal packages" are a real strange thing, we should
    not
    use that as this is complete eclipse specific.
Because it's focused on the grain on 1 bundle and not of a whole software piece, OSGi misses an important point about "internal APIs" which are things you want to expose to bundles that are build and shipped and tested together but don't want to maintain as a public API. There is a real need for it, and the x-internal/x-friends is so far the only viable solution as far as I'm aware. 
Or maybe there is some other mechanism I've been missing to cover that case?

    - https://enroute.osgi.org/FAQ/210-semantic_versioning.html
    <https://enroute.osgi.org/FAQ/210-semantic_versioning.html>
    [...]
    Sure Eclipse always has had its own "standards", but here I'm
    referencing to what most developers understand when using the term
    semantic versioning :-)
Seems like the Eclipse recommandations are very close to https://enroute.osgi.org/FAQ/210-semantic_versioning.html <https://enroute.osgi.org/FAQ/210-semantic_versioning.html> with extra stuff about extension points. So basically, Eclipse is doing proper semver already. 


_______________________________________________
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