release p2 more often?

[laeubi]

I found the recent discussions at tycho/ oomph and sharing/contribution code changes often has one hindering, that it is too inflexible because both projects don't want to wait for the next release.

What I'm wondering is: As far as I know there is nothing forcing p2 not leasing more often, so why not release every month/ week / day or even on every commit or on demand?

What would be required for this would be an automatic deployment workflow e.g we can deploy to eclipse-maven (as we deploy snapshots) automatically and deploy to maven-central the sim-rel.

Maybe p2 would even be the perfect 'reactor' to get experience with an automatic maven deployment (in contrast to the sim-rel based one) and a more flexible deployment workflow?

[mickaelistria]

even on every commit

That's what I-Builds are about.

[merks]

Indeed, Oomph uses integration builds....

[laeubi]

even on every commit

That's what I-Builds are about.

I don't think that I builds are suitable here:

1. I-Builds are moving targets, they vanish once in a while and are therefore lost after a short while
2. They don't offer maven-artifacts
3. I once asked for using the I-Build but @akurtakov has explained some issues why we can't use them (probably because of 1.) as then Tycho can't perform release

[merks]

Keep in mind too that p2 depends on other things. During the development cycle it might well be modified to depend on things that are specific and new in its dependencies. So if p2 were to release, it wouldn't necessarily work with the released versions of its dependencies. This type of problem is of course why we have SimRel in general and why often downstream projects don't wont to depend on new things because then they can't be installed anywhere expect the latest release...

[laeubi]

Keep in mind too that p2 depends on other things. During the development cycle it might well be modified to depend on things that are specific and new in its dependencies.

Then one goal might be to release that dependencies also more often :-)

In fact we don't need to promote these "mid-releases" in a way that they become available in regular eclipse products, but for tycho or eclipse-installer, who cares what version/release they use internally to perform their work as long as I can press "the download button" and it works?

[merks]

By p2's dependencies we're specifically talking the Eclipse UI, all of its dependencies, including the rest of Equinox. So we're talking about most of what we currently release 4 times per year. That seems infeasible...

[laeubi]

Of course we can concentrate either of two things:

1. Find as much things why it can't happen
2. Try it out and see if it can happen

I just checked the git history up to the beginning of the year, most of the changes are version bumps (due to releases) or internal work, don't see any required UI/equinox changes that would have required a never version ... So of course it is possible, but a great part of effort is put into backward-compat things so it won't be required to update dependencies that often. On the other hand, there are often smaller issues inside P2 and its always annoying to wait for the next release until they are bubbling up-stream (especially tycho).

So one "rule" might be that never release never uses unreleased features of its dependencies, and if we need to depend on never versions once in a while we can't release more often, but in all other cases are evolving faster...

[vogella]

@laeubi what do want as additional releases? Just a stable update site? I think it would be fine to create these on request even though I'm not sure what the process is. Or do you need more than just a stable update site? Would you use work against a "latest" update site? URL would be able but content might change.

[laeubi]

m2e for example provides release (update-sites) also between sim-rel releases and additional a 'latest' so one has the choice what suits best. Beside that, as tycho tries to consume more and more through maven (as we get automatic updates through dependabot) also an automatic maven deployment (at least to eclipse-maven as tycho does) would be a goal.

[vogella]

I think we already have a latest, try https://download.eclipse.org/eclipse/updates/latest IIRC @sravanlakkimsetti create this a while ago.

[vogella]

A big plus for an automatic upload to a Maven repo of our artifacts but I assume that would be a general issue for all platform components.

[laeubi]

We can leave of course tickets open even if we do not plan to work on them but I do not see value in this.

The value is that I or someone else might start work in that direction in the future and if someone complains we can reference this ticket and get more attention on the topic.

[merks]

I wonder if milestones such as 2022-06 M1 are published to Maven?

[sravanlakkimsetti]

I wonder if milestones such as 2022-06 M1 are published to Maven?

There are no plans for that as of now

[laeubi]

I wonder if milestones such as 2022-06 M1 are published to Maven?

At least here they are not show up (only 'final' versions): https://mvnrepository.com/artifact/org.eclipse.platform/org.eclipse.equinox.p2.core

[HannesWell]

I agree it would be beneficial if we would make P2 (and likely the entire platform) changes available to the Maven world more often.

1. Every I-build could be published into the OSSRH Snapshot repository
   At least Tycho-Snapshots could use them then immediately.
2. We could consider to release the milestones/release candidates with -M1/M2/M3/RC1/RC2 suffix.
   Other projects do that too: https://mvnrepository.com/artifact/org.apache.maven.plugins/maven-surefire-plugin

Although I find point 2 in general not very nice, without it projects like Tycho would have to wait until the next release of P2/Eclise until they can perform their next release. With Point 1 we would at least have the possibility to verify fixes quickly by using SNAPSHOTs. Therefore I think that is more important.

Publishing SNAPSHOTs is actually relatively simple. What is currently hindering us from running the I-builds up until the deploy phase (maybe using the nexus-staging-maven-plugin)?

• Another snapshotRepository in the distributionManagement section pointing to the corresponding OSSRH snapshot repo would have to be added.
• All artifacts would have to specify the group- and artifactId used for Maven-Central in their pom. IIRC this is currently modified?
• Because not all projects are intended for publication (e.g. tests) a mechanism to detect if a project is meant for publication would have to be implemented.
• Is there more?

Most of these 'hidden' projects are tests. Maybe Tycho could disable the maven-deploy/install-plugin by default for eclipse-test-projects. But the ultimate and actually only exact way would be to check if a project is contained in the just assembled I-build repo and to perform a deferred deployment at the very end. Maybe this could be done alternatively with some sort of script that runs the maven-deploy-plugin on each project to publish. Or we could create a plug-in for Tycho that similarly to the nexus-staging-maven-plugin defers the deployment to the very end and skips those project that are not in a "reference" p2-repo.

On the other hand isn't it is possible to create repositories that can be consumed by Maven and p2 at the same time?
If the I-Builds repo would have such format the problem would be resolved automatically.

[mickaelistria]

At the moment, only Tycho has such need, so it would make more sense to start working on a custom Tycho job that takes care of fetching p2 from latest I-Build, or even of rebuilding it.
Then, if there are other projects that find it beneficial, this can become something provided directly by p2; but with a single consumer it isn't yet profitable to put the pressure on the provider rathen than on the consumer.

[HannesWell]

At the moment, only Tycho has such need, so it would make more sense to start working on a custom Tycho job that takes care of fetching p2 from latest I-Build, or even of rebuilding it. Then, if there are other projects that find it beneficial, this can become something provided directly by p2; but with a single consumer it isn't yet profitable to put the pressure on the provider rathen than on the consumer.

Since most of the devs involved in Tycho are also involved in Platform and it IMHO does not make sense to distinguish here since in the end we are pushing pressure on ourself. And IMHO the time is invested better if done right once instead of doing it twice for different projects. And sometimes the consumers come only of there is an offer. :)

However since you work on a better resolution of Maven-dependencies, after the issues encountered in the Maven publication of the last release (eclipse-platform/eclipse.platform.releng#50), which should in the end simplify publication to maven-central and already suggested to publish snapshots of Eclipse-Platform (which includes P2, eclipse-platform/eclipse.platform.releng#58) I think this problem is (mostly) resolved with that. For example Tycho could then use the snapshots in its snapshots automatically, which at least would allow early testing and adaption for those that are willing to use Tycho-snapshots.
We could still think about publishing Milestones as releases (with M/RC suffix), but I think this should only be done on demand.