Update to 2025-09

[merks]

No description provided.

[merks]

This is just a draft. It's fully generated so it can be tossed away. I need to review it for missing things. If you see something that's missing, please let me know! I see the manifests are not updated...

[merks]

I see there are these:

And some more 4.36 things need attention.

[merks]

These remaining ones are relatively special:

And of course all these _NAME values should stay as the are now until after all the final tasks to update latest and create the new repos.

[jonahgraham]

After the needed fixup (#321) I am happy to see more of this automated.

The change from 2025-06-R -> 2025-09-M1 is much bigger than the change from 2025-09-M1 -> 2025-09-M2. Over time I reduced the latter to just be the entries in epp.website.xml + the block of main pom.xml. Because of this I was considering changing epp.website.xml to be a pre-processed file that was processed as part of the build. That would make it, for normal milestones, a change just to these sections of pom.xml:

packages/releng/org.eclipse.epp.config/parent/pom.xml

Line 38 in 7c04628

<RELEASE_MILESTONE>R</RELEASE_MILESTONE>

packages/releng/org.eclipse.epp.config/parent/pom.xml

Line 42 in 7c04628

<RELEASE_DIR>202506041200</RELEASE_DIR>

I would also be open to converting SIMREL_REPO back to a Jenkinsfile parameter. When I first removed all the parameters there were many of them, but if we save the SIMREL_REPO setting to https://download.eclipse.org/technology/epp/staging/_ci-info.txt then we can keep reproducible/recorded builds:

packages/releng/org.eclipse.epp.config/tools/upload-to-staging.sh

Lines 85 to 89 in 36da493

	# place a timestamp and CI build info in the directory
	echo "TIMESTAMP: $(date)" > _ci-info.txt
	echo "CI URL: ${BUILD_URL}" >> _ci-info.txt
	${SCP} -rp _ci-info.txt "${SSHUSER}:"${BUILDING}

(probably should have sha1 of git repo in there too)

The final change I want to make is removing the use of forceQualifierUpdate. Part of their original intention was to make the timestamps nice round numbers in the bundles, something that seems rather unimportant now for the hassle of doing it.

[jonahgraham]

Your program has found items that were missed in the 2025-03 to 2025-06 👍

[jonahgraham]

The next two lines should be:

    <PREV_RELEASE_NAME>2025-06</PREV_RELEASE_NAME>
    <NEXT_RELEASE_NAME>2025-12</NEXT_RELEASE_NAME>

These variables were added to make the steps to update this part of release.xml easier along with automating finalize-release

packages/releng/org.eclipse.epp.config/tools/promote-a-build.sh

Lines 92 to 106 in f715858

	<past>2024-12/R</past>
	EOM
	if [ "$RELEASE_MILESTONE" != "R" ]; then
	cat >> release.xml <<EOM
	<present>${PREV_RELEASE_NAME}/R</present>
	<future>${RELEASE_NAME}/${RELEASE_MILESTONE}</future>
	</packages>
	EOM
	else
	cat >> release.xml <<EOM
	<past>${PREV_RELEASE_NAME}/R</past>
	<present>${RELEASE_NAME}/R</present>
	</packages>
	EOM
	fi

So this step from releasing.md still needs doing:

packages/RELEASING.md

Line 29 in 48dba80

- [ ] Adding the previous past release explicitly to list in release.xml, located in promote-a-build.sh

[jonahgraham]

(Its quite annoying that putting comments on unedited lines is so hard in github - one of the things I miss about gerrit, anyway...)

A few lines below this is a TODO that is referenced from releasing.md that there are two ways of defining eclipse.simultaneous.release.name

[jonahgraham]

A small update missing on this line in all epp.products

Suggested change

	<repository location="https://download.eclipse.org/releases/2025-09" name="2025-06" enabled="true" />
	<repository location="https://download.eclipse.org/releases/2025-09" name="2025-09" enabled="true" />

[merks]

Re

The final change I want to make is removing the use of forceQualifierUpdate. Part of their original intention was to make the timestamps nice round numbers in the bundles, something that seems rather unimportant now for the hassle of doing it.

There have been a number of occasions where it's proven useful that each feature updates with each milestone, i.e., for the Notification framework I can show the "update to a milestone notification" only if folks don't have the latest milestone installed.

I find it a very small detail and I simply use "run external program" to run it.

[jonahgraham]

number of occasions where it's proven useful

OK - I will not aim to remove it. My first step was trying to verify if it was usable by someone anyway, so thanks for being proactive and sharing the use case.

[merks]

I’ll share my updater very soon and then we can discuss the automation details more concretely. I think we are on a good track though. It’s nicer to automate what needs to be done than document it and do it manually.