search

eclipse-windowbuilder / windowbuilder

Eclipse Windowbuilder
https://projects.eclipse.org/projects/tools.windowbuilder
Eclipse Public License 1.0
78 stars 30 forks source link

1.12.0 Releng #438

Closed wimjongman closed 1 year ago

wimjongman commented 1 year ago

A document to catch releng issues for 1.12.0

merks commented 1 year ago

I'll leave the timeout at 90 minutes. I've kicked off a milestone build just to see how that goes...

Keep in mind next Wednesday is the deadline for the release.

merks commented 1 year ago

FYI, the build completed in 52 minutes so there is a large variation in the completion time and 50 minutes is clearly too short.

merks commented 1 year ago

@ptziegler

I will produce a final milestone build tomorrow for contribution to SimRel. Though I'm not sure I need to because I see no commits after the one that increased the build timeout:

https://github.com/eclipse-windowbuilder/windowbuilder/commits/master

If something else needs to be committed for the final milestone build, now is the time...

ptziegler commented 1 year ago

Though I'm not sure I need to because I see no commits after the one that increased the build timeout:

The past few days have been a little busy, so I had little time to work on the WindowBuilder. :sweat_smile: I still have a few pull requests open, but as you mentioned a few days ago: Given that they affect sensitive areas, I think it's it's better to hold them off so soon before the release.

That said, I think we haven't updated the versions in the Manifest files since the previous release, even though all have been changed since them, due to the Java 17 update, for example. I've played around with the tycho-baseline-plugin to see what the suggested new versions are, and a lot of them would require a major version increase, due to e.g. the removal of CGLib and the GEF migration.

See #470

Thoughts?

merks commented 1 year ago

I doubt there are downstream extenders who are using WindowBuilder plugins as API and even if there are I doubt they will be well served by major version increments. E.g., Was CGLib exposed in the APIs? Looking at the ByteBuddy usage, that appears to be just an internal implementation detail. I can't really tell the reasons for the major version increments just looking at the PR...

In any case, today is the last to produce a new build for SimRel, if needed...

ptziegler commented 1 year ago

Was CGLib exposed in the APIs?

It was only ever used internally, which is why I'm reluctant with a major version increase.

Hm... I wonder if I can configure the baseline plugin in such a way, that it ignores all packages that contain "internal". Until when do you need to contribute the new build, if necessary?

merks commented 1 year ago

We (I) can contribute a build quite late in the day today.

I think such packages can be marked x-internal. I'm not sure if using x-friends implies that it's internal too, e.g.,

image

No doubt if you do that now, the tools will complain that you've removed API and must do a major version increment...

ptziegler commented 1 year ago

I think such packages can be marked x-internal. I'm not sure if using x-friends implies that it's internal too, e.g., No doubt if you do that now, the tools will complain that you've removed API and must do a major version increment...

As far as I can tell, Tycho internally calls the bnd-baseline-plugin, which supports the exclusion of specific packages. The documentation even contains a similar example:

For example, you want to match all implementation packages (i.e. they have impl in their name) except when they start with com.example. This can be achieved with: !com.example.impl, .impl.

But I think I just have to take some time and see how this works, exactly. In any case, for the next build, I think it's the most effective if I increase the micro version of all bundles, without using any baseline check.

As far as I can tell, the public API hasn't changed and every bundle has been affected by the Java 17 update.

merks commented 1 year ago

Yes, I think a simple minor or micro increment is fine and non-disruptive...

ptziegler commented 1 year ago

Hm... The builds time out again, even though I've only changed the Manifest versions. What's going on with the Jenkins node? 😕

merks commented 1 year ago

I thought I changed it to 1.5 hours before...

I see there is now a new milestone that I can contribute. OK?

ptziegler commented 1 year ago

I thought I changed it to 1.5 hours before...

The Jenkins job is set to 1.5h. But the tests themselves also have a 60min timeout, in order to not block the GitHub builds. The tests finished yesterday within 35min, which is what they usually take. And I don't really want to arbitrarily increase the timeout without understanding the underlying problem.

So no, there's nothing to contribute. ☹️

merks commented 1 year ago

@ptziegler

Both of your PRs from today are merged and a nightly build has kicked off and is currently running. Once that's done I will do a milestone build and then immediately a release build. Then 1.12.0 is done. Is that OK?

Then I can contribute the release repository URL to SimRel in time for tomorrow morning...

merks commented 1 year ago

With the latest build failure I see that this repo, which WB uses,

https://download.eclipse.org/tools/gef/classic/latest/plugins/

overwrites its contents whenever a new build is published there. That can be right in the middle of WB's build using it. Argh.

That's why we create each nightly build in new repository location, so that the rug isn't pulled out from under someone...

ptziegler commented 1 year ago

Both of your PRs from today are merged and a nightly build has kicked off and is currently running. Once that's done I will do a milestone build and then immediately a release build. Then 1.12.0 is done. Is that OK?

Sure, go for it!. WindowBuilder should be ready for the release.

ptziegler commented 1 year ago

The "Reorganize Update Sites" item is still open but as far as I can tell, the new update is complete. Is there anything left that needed to be done for the 1.12 release?

And given that we're part of the release train, I assume we also have to start preparations for the 1.13 release in autumn? Or do we instead try to go for a bi-annual release?

merks commented 1 year ago

There is no strict requirement to do quarterly releases but surely the user would appreciate each release train repository containing bug fixes and enhancements and using the latest dependencies so I think it’s a good idea to plan for this.

ptziegler commented 1 year ago

I'm closing this one as the 1.12.0 release has already been done. Upcoming issues are handled as part of #504