Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [m2e-dev] Version/Release/Compatibility Policy

r


On Wed, Aug 31, 2022 at 7:50 PM Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx> wrote:
The M2E `/latest` update site got broken because it suddenly depends non *none official*, *none released* artifacts of other Eclipse projects.

That's indeed a kind of glitch in the process.
m2e doesn't use milestones repositories as they're usually not so useful. Here those would have been useful, as the goal was to be able to contribute a m2e release that had colored console for upcoming SimRel. So as m2e has only releases and not milestones, and we don't want snapshots in SimRel, as a consequence the release took place a bit too early after the dependency chain leading to this temporary inconsistent case.
However, the release is built on frozen APIs, so the versioning still technically correct. The only issue is that people cannot get the latest release immediately before they upgrade Platform, but as long as older releases are still available, it's easily manageable.

> My recommendation is to implement something similar for M2E.

I may be wrong, but I believe none of the current committers is interested in spending significant effort this for such N-2 Platform release compatibility. But contributions are welcome (as long as they don't have as side effect to reduce capacity to innovate or to reduce technical/functional quality).

On Wed, Aug 31, 2022 at 7:50 PM Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx> wrote:
Greetings M2E Committers,

I'd like to make you aware that M2E has a significant user base outside of the committer bubble. Quite a a significant amount of these users are enterprise customers, which do expect some kind of stability, compatibility and announcements around upcoming breakages.

Lately, an issue that I ran into myself within the organization I work with is this:

The M2E `/latest` update site got broken because it suddenly depends non *none official*, *none released* artifacts of other Eclipse projects. This is not only problematic from a customer/user point of view, it's also problematic from an Eclipse Development Process and IP process point of view. As a member of the Technology PMC, the latter is more concerning for me.

It's a good practice for mature, stable Eclipse projects, with a significant user base, to create and publish a version/release/backwards compatibility. As an example, the Eclipse Git integration generally tries to support the last N-2 Eclipse versions with their releases. I do consider M2E as important as EGit and thus, my recommendation is to implement something similar for M2E.

I think that at a very minimum, the `/latest` update site should point to a release, which does not depend on unreleased artifacts.

Appreciate your support and respect of the EDP and best practices.

.Gunnar

-- 
Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx, http://guw.io/



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


--
Mickael Istria
Eclipse IDE developer, for Red Hat Developers

Back to the top