search

eclipse-cbi / targetplatform-dsl

Target Platform Definition DSL and Generator
Eclipse Public License 2.0
76 stars 38 forks source link

[#56] resolve all declared version ranges per IU ID #145

Closed haubi closed 7 months ago

haubi commented 7 months ago

Regarding version overrides:

haubi commented 7 months ago

Wouldn't this slight behaviour change deserve some version bump somewhere?

merks commented 7 months ago

Given there are only nightly build for the 3.0.0 version and no releases, it's not really clear what if anything incremented:

https://download.eclipse.org/cbi/updates/tpd/nightly/latest

Eventually after 5 builds, all the older versions are gone, so what could any consumer do with the version?

haubi commented 7 months ago

Given there are only nightly build for the 3.0.0 version and no releases, it's not really clear what if anything incremented:

https://download.eclipse.org/cbi/updates/tpd/nightly/latest

Eventually after 5 builds, all the older versions are gone, so what could any consumer do with the version?

At least wondering a little less about changed behaviour when the version number has changed. Actually, even if there's lack of manpower for proper release management, at least we can increase the revision numbers, no?

merks commented 7 months ago

It's really, really, easy to produce milestones and releases, but no one ever asked so I assume no one really cares about that. For other projects I use Oomph's version tool so that if something changes it tells you to change the version and has quick fixes for it. So none of this is a lot of work., if anyone cares. But there's no point in doing work if everyone happily consumes nightly builds with the latest. In the end versions matter most to downstream bundles that use these bundles, but I think this stuff is mostly and end-user tool...

haubi commented 7 months ago

Well... we do (have to) care, and we actually take nightly snapshots as "releases", and the publishing/archiving of those "releases" we do within SDC Server, where we still have need for these "releases" of TargetPlatform DSL to be around: 2.1.1.201410251450 3.0.0.201809052136 3.0.0.201902111444 3.0.0.202301141839

merks commented 7 months ago

I see!

haubi commented 7 months ago

Is there something wrong with Jenkins ATM?

merks commented 7 months ago

It's failing like this:

15:04:10 [ERROR] /home/jenkins/agent/workspace/targetplatform-dsl_PR-145/scm/org.eclipse.cbi.targetplatform.model/META-INF/MANIFEST.MF [7:0]: Unqualified OSGi version 3.1.0.qualifier must match unqualified Maven version 3.0.0-SNAPSHOT for SNAPSHOT builds The pom version must be modified if the feature/bundle version is modified.

merks commented 7 months ago

I'm traveling tomorrow, won't have time for a proper review until the weekend. Probably it's a good idea to create a release repository for the 3.0.0 version without these changes first. What do you think?

haubi commented 7 months ago

Probably it's a good idea to create a release repository for the 3.0.0 version without these changes first. What do you think?

Whatever this exactly means: Yes, sounds meaningful!

haubi commented 7 months ago

I'm traveling tomorrow, won't have time for a proper review until the weekend.

Never mind, I'm offline for the rest of March anyway.

merks commented 7 months ago

@Bananeweizen @hannesN

Do you guys haven an opinion about:

  1. The proposed change, which looks quite simple and appears well-tested.
  2. The value of producing release repositories.

E.g., here is an example of a project milestones and releases in their update site:

https://download.eclipse.org/nebula/updates/

Here's documentation about the structure:

https://eclipse.dev/justj/?page=tools#p2-anatomy

The point is that if a release is produced, the repository will exist permanently whereas all the nightly builds are effectively transient...

opcoach commented 7 months ago

A release repository is a must have. We could then use it in a specific pom to generate the target from the tpd (as it seems not possible to do it in the project main pom).

And the next step would be to have the ".tpd -> .target" transformation directly in the Tycho target-platform-configuration Mojo.

Bananeweizen commented 7 months ago

Regarding change: It looks okay to me. First I was surprised reading about this bug. I had never experienced it, although of course we use javax and jakarta stuff in different versions. However, we had started using maven dependencies even before they were supported in this DSL (wrapping them via https://github.com/reficio/p2-maven-plugin), so we avoided it without knowing. :)

For versioning and releasing: I'd be really happy with that, as I'm a big fan of "everything as code" as well as "reproducible builds". Until now my personal strategy has been to version the generated file, so even with the TPD support potentially vanishing, there would be no desaster. And in the past, the TPD format has been compatible over a long time, so even older files would work fine in newer versions of the TPD conversion. Therefore I didn't put a high priority to this until now, but I would of course enjoy it.

And if we are already doing a kind of planning here: I would also like to do some modernization of the code. E.g. lift it from Java 8 to 17, and make versions generally more strict. Right now it doesn't even compile in Java 21 (due to Xtend cross compilation ambigitious with new methods), etc. I guess it would be best to raise separate issue for discussing that, as the release activities should best be applied before such incompatible changes.

merks commented 7 months ago

@Bananeweizen

So I think we (I) should produce a release for the current state before many any other significant changes. All the things you describe could go into 3.1.0 then, right?

merks commented 7 months ago

I did the first milestone build so the repository now has (and always will have) this:

https://download.eclipse.org/cbi/updates/tpd/milestone/latest

Publishing a release effectively involves mirroring the artifacts from this repository to a permanent location.

So unless someone thinks something else should be in the 3.0.0 release and is not already in the milestone/latest I could publish a release anytime...

Bananeweizen commented 7 months ago

So unless someone thinks something else should be in the 3.0.0 release and is not already in the milestone/latest I could publish a release anytime...

Sounds good to me, since it just gives a fixed point to the ever moving baseline of the past. If I understood you right, releasing the next (and next, and next...) version would be rather simple (because of automation), so there is not much benefit from waiting for more PRs, IMO.

merks commented 7 months ago

Yes it's must a matter of choosing the type of build:

image

The management of the update sites is completely automatic. Even the milestones are cleaned up once a milestone with a higher version is published.

So if someone says, "I want to produce a release update site now" it would take < 10 minutes; < 5 if there is always a milestone that one wants to promote to a release, as is the case now.

merks commented 7 months ago

@Bananeweizen

I think all the cleanups are done. I made one final change to get ride of the deprecation warnings and build this milestone

https://download.eclipse.org/cbi/updates/tpd/milestone/S202403241316/index.html

If I hear nothing that speaks against making this the 3.0.0 release by the end of the day tomorrow (March 25th), I will promote this to a release...

Bananeweizen commented 7 months ago

Thanks, @merks . I also have zero warnings now in Eclipse. I have just some of the remote tests failing, but that's to be expected with our company proxy. I'll check later if I can find some fix for that.

merks commented 7 months ago

I've produced the release repo and did a first commit with the version increments. Then I cherry picked the commit with the actual implementation changes which are now part of the PR:

https://github.com/eclipse-cbi/targetplatform-dsl/pull/155

So this PR is now obsolete.