-
Notifications
You must be signed in to change notification settings - Fork 17
Lyo Release Process
Actions to improve instructions the next time they are used.
- In Phase1, when creating the release note, include the Change log from both Lyo and Lyo designer. This means, we need to have links to both ChangeLogs. This also means we need to tag the LyoDesigner repo (next point)
-
Include instructions to tag LyoDesigner releases, in same way we tag Lyo.
- _This however means that some LyoDesigner steps need to be done in Phase1. _
- So, instead of Part1 (Lyo) and Part2 (LyoDesiger), we need a general Phase1, before we do specific Lyo/LyoDesigner steps.
The plan is to make two releases: one candidate and one final. Suggested version qualifiers are suggested below (Maven version sort reference):
Stage | SDK version | Designer version |
---|---|---|
devel | 4.0.0-SNAPSHOT |
4.0.0.qualifier |
alpha/beta | 4.0.0.Alpha |
4.0.0.Alpha |
candidate | 4.0.0.CR |
4.0.0.CR |
final (release) | 4.0.0.Final |
4.0.0.Final |
devel-next | 4.1.0-SNAPSHOT |
4.1.0.qualifier |
NB! Make sure to always to a Git revert after you made a candidate (or alpha/beta/milestone) release. This avoids double deploy of non-SNAPSHOT artifacts that can break the Jenkins build.
- Check the handbook and determine the next available Wednesday slot (should conclude on the 1st or 3rd Wed of the month) for the release.
- When making a
CR
, create a release. Paste the CHANGELOG into he Description under the Basic tab; select Type A diligence. - Check for the date of the last Progress Review through https://gitlab.eclipse.org/eclipsefdn/emo-team/emo/-/issues/?sort=created_date&state=all&search=lyo&first_page_size=20. Do the following steps only if more than 1 year passed since the last Progress Review:
- Request Progress Review through the "Create a Progress Review" from https://projects.eclipse.org/projects/technology.lyo. This request will land at EMO and they will create a Gitlab ticket.
- Follow these instructions to automatically create IP Team Review Requests https://github.com/eclipse-dash/dash-licenses?tab=readme-ov-file#automatic-ip-team-review-requests
- Request a release approval from the PMC once you have a Gitlab link and (preferable, but not strictly necessary) an approval of the IP log. You can do this from the "Send Email to the PMC" you can find under https://projects.eclipse.org/projects/technology.lyo. Send a simple email, with simple links to the release entry, Gitlab ticket should be enough.
- While you wait 2 weeks, make a candidate CR1 release . Email lyo-dev to invite people to test it.
- After you get a GO decision for the release, Make a candidate CR2 release - IF significant changes were made to the repo since CR1.
- Test and email CR info to lyo-dev and wait 24h. Also test that the refimpl works with the CR.
- When ready to make the final release, edit and update the release note (on https://projects.eclipse.org/projects/technology.lyo/) - iff necessary
- Only necessary, if - for example - you need to update the release date.
- Make a final release (See steps below)
- Announce on lyo-dev, oslc-op, and the OSLC Forum.
Minor releases on Eclipse require release review. Make sure to schedule one ASAP, they only take place twice a month.
- Make sure you are on master and the repo is clean and pulled.
- create a new branch
mvn versions:set -DnewVersion="4.1.0.xx"
- If the release is a
Final
one, edit theCHANGELOG.md
and replace[Unreleased]
with[#.#.#]
- Push that new branch and create a PR.
- if the release is
Final
, get at least one approval. - Once reviewed & approved, merge the PR to master.
- Wait for the build to succeed on Eclipse Lyo Jenkins.
- Pull the latest master, and tag the release
-
git tag v4.1.0.xx
(previously, final releases were tagged without "final". In future, we should add "final" to the tag.) git push --tags
-
- Create a draft release note under https://github.com/eclipse/lyo/releases.
- if you are releasing a candidate, check the "Set as a pre-release" checkbox
- Set the appropriate tag under "choose a tag"
- Duplicate the relevant content from the ChangeLog, but also add a statement that "This content is a duplicate of the Change Log (make sure to point to the tagged revision, not to master)
- Once done, save by pressing “Save draft” (and not “publish release”)
Steps:
- Edit the pom.xml of the refImpl to set the Lyo version to that of the relesae to test.
- Go to the Refimpl Actions
- click run workflow
- wait for success.
- Log in to https://oss.sonatype.org/#welcome (legacy host, Lyo is on the "legacy" host)
- go to Staging Repositories.
- Select the listed Lyo repository and click Close. This may take a few minutes. See OSSRH docs for more info.
- Click Release (you may need to refresh first (every few minutes)). In pop up window, leave Automatically Drop option ON unless you know what you are doing (the release action is irreversible anyway).
- Publish the previously saved draft (pre)release note under https://github.com/eclipse/lyo/releases
- Keep refreshing on sonatype from time to time (every few minutes). When the list becomes empty, the release is finished!
- Visit https://repo1.maven.org/maven2/org/eclipse/lyo/oslc4j/core/oslc4j-core/ to check if the artifacts were promoted to Maven Central from OSSRH already (this usually takes around 2hrs).
Once you have confirmed that the release build has concluded, you can do these steps, no need to wait for the Maven Central promotion.
if you released a milestone build, revert the release comment to go back to the snapshot version:
git checkout master
git pull
git revert --no-commit HEAD
git commit -m "Continue the SNAPSHOT development"
git push
If you released a final
release, use versions:set
to set the next planned version with the SNAPSHOT
modifier, e.g. for 4.1.0 release:
git checkout master
git pull
mvn versions:set -DnewVersion="4.2.0-SNAPSHOT"
# Edit the `CHANGELOG.md` and add the `[Unreleased]` template from the bottom of the file to the top
git commit -m "Continue the SNAPSHOT development"
git push
Notes relating to the dependencies between Lyo Designer and the Lyo SDK:
- the OSGI bundles module (org.eclipse.lyo.oslc4j.plugins) depend on a specific version of the Lyo SDK. This is set with
<properties>...<lyo.version>...</lyo.version></properties>
- Lyo Designer (org.eclipse.lyo.tools.toolchain.design) proposes a default version of the Lyo SDK for newly created models. This can be see in the 4+ places in the file
description/ToolChainModel.odesign
, by searching forfeatureName="lyoVersion" valueExpression=...
Before starting the release process for Lyo Designer
- Finalize the release process of the Lyo SDK.
- Update the above modules, to refer to the released Final version of the Lyo SDK.
- Push the changes to master for LyoDesigner
- Start the release process for LyoDesigner
Links:
Stable:
You will need to run the steps below twice. First to release a candidate (eg. 4.0.0.CR), and then - if all goes well - make a final release (4.0.0.Final). The same steps apply for both phases, except for the choice of version number. The final step has a variation, which is detailed below.
- Switch to the master branch of LyoDesigner and do a
git pull
. - Create a new branch for the release.
- Run on the command line (cd to lyo.designer folder first):
mvn -f pom.xml org.eclipse.tycho:tycho-versions-plugin:set-version -DnewVersion='<versionNumner>' -DforceStdout -B
- Set to, e.g.,
4.0.0.CR
or4.0.0.Final
- That is, make sure to add .Final to a final version. Otherwise update will not work.
- Set to, e.g.,
- For the org.eclipse.lyo.oslc4j.plugins artifact, manually update the artifact version. (this is not updated via the Tycho plugin above)
- Run the following commands in bash to verify a clean version update. Besides test plugins, there should be no artefact that refers to a qualifier nor SNAPSHOT version:
grep --exclude-dir=.git --exclude-dir=target --exclude-dir=bin -rE "qualifier" . 2>/dev/null
grep --exclude-dir=.git --exclude-dir=target --exclude-dir=bin -rE "SNAPSHOT" . 2>/dev/null
- Push the branch and make a pull request.
- Merge. This will trigger the CI build to create artefacts on edge. (might want to go to https://ci.eclipse.org/lyo/job/lyo-designer-master/ and manually start the build to make it faster)
- Once edge is built, download/update and test LyoDesigner.
- Does it work in general?
- Does it generate code as expected?
- Does it have the correct plugin versions? Select
Help > About Lyo Designer > Installation Details
and then check the versions ofInstalled Software
. - In a generated OSLC Server, make sure that the generated
Application
class has the right version ID, e.g. Generated by Lyo Designer 4.0.0.CR and DOES NOT include a timestamp. Timestamp is a sign of a.qualifier
version in OSGI manifests.
- run the release job https://ci.eclipse.org/lyo/job/lyo-designer-release/build?delay=0sec to copy artefacts from edge to stable THis will prompt you for the version id. (e.g.,
4.0.0.CR
or4.0.0.Final
). - Once stable is built, run the promote job https://ci.eclipse.org/lyo/job/lyo-designer-promote/. THis will prompt you for the version id. (e.g.,
4.0.0.CR
or4.0.0.Final
) - Bring the
master
branch to a SNAPSHOT/qualifier state. This steps differs depending on whether you just made aCandidate
(e.g., alpha1, beta1, CR) orFinal
release.- If you made a Candidate release
- Do a Git revert and push this commit.
- Go to Step 1 above to do the final release
- If you made a
Final
release, push the changes below directly to master- Bump the version number up a bit:
mvn -f pom.xml org.eclipse.tycho:tycho-versions-plugin:set-version -DnewVersion='<versionNumber>' -DforceStdout -B
. Set the<versionNumber>
to something such as4.0.1-SNAPSHOT
or4.1.0-SNAPSHOT
. - For the org.eclipse.lyo.oslc4j.plugins artifact, manually update the artifact version. (this is not updated via the Tycho plugin above)
- For the org.eclipse.lyo.oslc4j.plugins artifact, manually change the Lyo version from which the plugins are to be made. (preferably, the same version as what was just been bumped to).
<lyo.version>4.1.0-SNAPSHOT</lyo.version>
- Commit and push the changes to master. (can have the message "Continue the SNAPSHOT development")
- The new snapshot will be built and released to "edge"
- You are done!
- Bump the version number up a bit:
- If you made a Candidate release