LSP4J 0.22.0
jonahgraham opened this issue · comments
This is the Release plan and TODO list for LSP4J release v0.22.0.
Steps for Release
Items at the beginning of development
- Create an Endgame Issue to track the release. As a starting point use documentation/releasing.md.
- Add the Endgame label and Milestone for the release
- Make sure any previous edits made to Endgame issues of previous releases are updated in documentation/releasing.md
- Ensure all previous Endgame issues are done.
- Create a New milestone for the release
- Check CHANGELOG.md is up to date. The changelog should have a version entry, release date, API Breakages and other information consistent with current entries in the changelog.
- Check README.md is up to date. In particular that the planned release and which versions of DAP and LSP are support is listed.
- Increment version of all feature.xml, pom.xml and any other place full version is used. (Easiest way is global find and replace, e.g.
s/0.21.0/0.22.0/g,s/0.20.0/0.21.0/gand review changes.) Ensure that-SNAPSHOTis restored in the gradle/versions.gradle and releng/pom.xml - Enable
sh './releng/deploy-build.sh'in releng/build.Jenkinsfile - Ensure the CI build is stable - it is always better to release a "Green Dot" build
Items in the days ahead of Release day:
- Create release on PMI
- Schedule the release and if needed schedule a release review on the PMI. A release review is needed every 12 months, not with each release.
- Check CHANGELOG.md is up to date. The changelog should have a version entry, release date, API Breakages and other information consistent with current entries in the changelog.
- Check README.md is up to date. In particular that the planned release and which versions of DAP and LSP are support is listed.
- Check all closed PRs and Issues to make sure their milestone is set. (Note: this was not until after 0.10.0 release so many old PRs and Issues have no milestone, therefore only consider items back to approx 5 Nov 2020). This search may be useful to identify such closed issues
- Create and analyse a
japicmpreport and publish it as part of the build. Ensure that the API versions are incremented accurately based on the report. The reports are part of the build in japicmp-report and generated byreleng/runjapicmp.sh - Update links in changelog for japicmp from the nightly to the final location
Items on Release day:
- Prepare the repo for release by:
- removing
-SNAPSHOTfrom gradle/versions.gradle - removing
-SNAPSHOTfrom releng/pom.xml entries in<dependencies>section. - disabling
sh './releng/deploy-build.sh'in releng/build.Jenkinsfile - see commit 328ce8a for a past example
- removing
- Push the above change
- Run the CI build
- Mark the build as Keep Forever and add to the description
v0.22.0 - Deploy the release by running the Release CI job with parameters:
LSP4J_PUBLISH_LOCATION->updates/releases/0.22.0( <-- check version number)PROJECT->lsp4j-multi-build/job/mainLSP4J_BUILD_NUMBER-> the build that was just run aboveDRY_RUN->false
- Add to the deploy job description
v0.22.0 - Promote the staged repository to maven central
- Login to Nexus
- To obtain permission add request to OSSRH-26079
- go to Staging Repositories, after a short delay the staged LSP4J release should appear (you may need to press Refresh)
- click the staged LSP4J repo
- press the Close button located in the toolbar. This runs activities, including checking various rules
- once the rules are done (if successful), press the Release button (you may need to press Refresh to enable the Release button)
- check https://search.maven.org/search?q=g:org.eclipse.lsp4j to make sure the latest release has arrived - this takes a while, 15 minutes for the files to be on the server and even longer for the search indexes to update
- Login to Nexus
- Update the meta-data on PMI downloads page
- Tag the release. Example:
git tag -a v0.22.0 HEAD -m"LSP4J 0.22.0" && git push origin v0.22.0 - Contribute to Simrel. See Simrel contribution example
- Create a release page on github
- Link the Changelog to the release page
- Make an announcement on lsp4j-dev based on the release page on github. Example on lsp4j-dev archives
- Update documentation/releasing.md with any changes that may have been made to the release process.
- Create the endgame for the next release right away, especially as version numbers and restoring
-SNAPSHOTneed to be done right away.
Because of fixes to handling 3rd party libs we need to do a release (or pre-release) of LSP4J so that we can see the effects in SimRel and resolve what Ed raised in https://www.eclipse.org/lists/cross-project-issues-dev/msg19709.html
I can do a release now, but because of the current dep on a milestone of xtend I don't know if that is a good idea (#751)
@cdietrich thoughts?
The problem is I changed jobs on 1st so I won’t be really able to contribute much (specially on Xtext side )
Hmmm... Is it even allowed to use yet-to-be-released content of other Eclipse projects in a release? IIRC, it was not allowed in the past...
Xtext has to my knowledge no dep to the generator so we might be able to live with a broader range von Xtext side
And thus consume an older maven dependency.
and in p2 include the newer on (doing the 2nd release after the Xtext release
@szarnekow @tivervac any comments from your side
Hmmm... Is it even allowed to use yet-to-be-released content of other Eclipse projects in a release? IIRC, it was not allowed in the past...
It still is not - we are not going to release that content and #751 needs resolving to make sure that is handled.
Xtext has to my knowledge no dep to the generator so we might be able to live with a broader range von Xtext side And thus consume an older maven dependency. and in p2 include the newer on (doing the 2nd release after the Xtext release
@szarnekow @tivervac any comments from your side
@cdietrich Is your question whether we use the org.eclipse.lsp4j.generator plugin? If so, we do not.
Regarding LSP4J, we can make our range wider, but only if backward compatibility is ensured of course
Yes this is what I meant: use current lsp4j in xtext release, but allow newer release in manifest so that simrel can pull newer lsp4j
I don't think LSP4J does semantic versioning (same as Xtext). This will make it a bit harder. I can see that it'd work to depend on LSP4J[current, current+2) instead of LSP4J[current, current+1) but this would also only reduce the probability of allowing inconsistent OSGI resolution.
Can I release lsp4j 0.21.1 with guava dependency range increased to: '[30.1.0,33)'?
Can I release lsp4j 0.21.1 with guava dependency range increased to:
'[30.1.0,33)'?
This is what I mean explicitly: #759
Hey there, any idea when 0.22.0 is gonna land?
I think we should schedule this to release, well in time for 2024-03 M3? That would mean around or before 13 Feb.
cc: @cdietrich @mickaelistria @pisv for input on dates and coordination with your consumption of LSP4J. In particular, it would be nice if we all had 2024-03 using the same version of LSP4J.
we wont have a new xtend release though. otherwise ok.
do we already know if there will be any api changes upstream in the protocol?
Because of https://status.eclipsestatus.io/maintenance/315201 I may have trouble getting 0.22.0 done today. Builds are not running on Jenkins with errors like "forbidden: exceeded quota: jenkins-instance-quota"
I'm part way through the release steps but I have to step away for a meeting. I'll resume later today.
The release is now complete. The maven should update once their scripts run and I am now preparing the repo for 0.23.0 development (And can prepare for 0.22.1 if needed)