Jetty/Contributor/Eclipse Release
Contents
Eclipse Release Checklist
If its a bugfix release then you are fine to release.
If its a minor version bump then you must follow the process below.
- At least 3 weeks ahead of time, make sure we have a frozen IP Log in place, otherwise submit one to Eclipse Legal for review
- http://www.eclipse.org/projects/ip_log.php?projectid=rt.jetty
- at bottom the this url click the 'Submit IPLog' button, it gets mailed to Wayne who goes through it with a fine toothed comb
- this step may be skipped if reusing an existing IPLog, which is commonly the case for our minor releases and speeds the process greatly
- Create release directory under admin in svn: svn+ssh://dev.eclipse.org/svnroot/rt/org.eclipse.jetty/admin/<release version>
- Create Release Review Document
- template in svn @ admin/template/JettyReleaseReviewTemplate.odp
- alternately grab the last release review and update it into a new name, the edit the slides accordingly
- copy into new release directory and commit accordingly
- release review document should have hard link to the IPLog being used for the release, this document can not be submitted until finalize IPLog is in place
- Email Release Docuware to emo@eclipse.org requesting a release review
- explain briefly what has changed and why this can't be a bugfix release, updates to protocol like websocket, etc
- release reviews are generally on a Wednesday and out about 2 weeks from when you ask for them, ask for as soon of a date as possible
- prepare to hear back that there are no RC# releases for the release review being scheduled and then respond that we don't typically require a full on RC# release in our process.
- wait until required time has passed and release review was successful
- release!
Jetty-rt-bundles Release build: Hudson Job
How-to build Jetty/Contributor/Update Site
Run the Hudson job 'jetty-rt-bundles'
The parameterized hudson job https://hudson.eclipse.org/hudson/view/Jetty-RT/job/jetty-rt-bundles/ is in charge of building the jetty-rt-bundles repositories.
Parameters:
- jetty-version: choose jetty-7 or jetty-8 (default: jetty-7)
- pack-and-sign: enable signing and packing the artifacts (default: yes)
- jetty_release_version: enter which built version of jetty to use. (default: will choose the latest snapshot)
The last 2 parameters are unlikely to be changed.
- force_context_qualifier: to force the produced feature to use a specific number. (default timestamp)
- set_pom_version: force the pom.xml to use a new version. (default use the one committed in svn).
Add the new repository to the composite repository
For jetty-8; edit: sftp://youruser@build.eclipse.org/home/data/httpd/download.eclipse.org/jetty/updates/jetty-bundles-8.x/compositeArtifacts.xml and sftp://youruser@build.eclipse.org/home/data/httpd/download.eclipse.org/jetty/updates/jetty-bundles-8.x/compositeContent.xml Make it a +1 for the number of children. Add a <location> line.
The process for jetty-7 is identical.
EclipseRT WebStarterKit
How-to build Jetty/Contributor/Update Site
Run the Hudson job 'jetty-rt-bundles'
The parameterized hudson job https://hudson.eclipse.org/hudson/view/Jetty-RT/job/jetty-rt-products/ is in charge of building the jetty-rt-products repositories.
Parameters:
- jetty_rt_branch: indigo / juno (default indigo)
- platform: choose which version of equinox (default indigo-nightly)
- pack-and-sign: enable signing and packing the artifacts (default: yes)
- rt_release_version: Name of the release that will be suffixed by a timestamp: for example 'S-3.7RC4'.
- jetty_release_version: enter which built version of jetty to use. (default: if equinox-nightly then use jetty-snapshot; otherwise use the composite repository to point to the latest released version of jetty)
- set_pom_version: force the pom.xml to use a different version then the one committed in svn.
Add the new repository to the composite repository
For jetty-8; edit: sftp://youruser@build.eclipse.org/home/data/httpd/download.eclipse.org/jetty/updates/ -replace-by-actual-folder- /compositeArtifacts.xml and sftp://youruser@build.eclipse.org/home/data/httpd/download.eclipse.org/jetty/updates/ -replace-by-actual-folder- /compositeContent.xml Make it a +1 for the number of children. Add a <location> line.
Jetty-rt local builds
Local builds are run with maven3.
Jetty-rt-bundles
- jetty-rt-bundles for jetty-7: svn co http://dev.eclipse.org/svnroot/rt/org.eclipse.jetty/eclipse/jetty-bundles/jetty-7/
- jetty-rt-bundles for jetty-8: svn co http://dev.eclipse.org/svnroot/rt/org.eclipse.jetty/eclipse/jetty-bundles/jetty-8/
mvn clean verify
The repository produced is here: ./jetty.bundles.repo/target/site
Jetty-rt-products
- jetty-rt-products for Indigo (jetty-7): svn co http://dev.eclipse.org/svnroot/rt/org.eclipse.jetty/eclipse/jetty-rt-indigo/
- jetty-rt-products for Juno (jetty-8): svn co http://dev.eclipse.org/svnroot/rt/org.eclipse.jetty/eclipse/jetty-rt-juno/
mvn clean verify
The repository produced is here: ./jetty-features/org.eclipse.jetty.product/target/repository
Consuming the jetty-rt-bundles built locally in the local jetty-rt-products build
There is currently no process/convention to 'install' a repository produced by a local build into a location where it can easily be consumed by another tycho build such as the jetty-rt-products build.
So at the moment, it is required to edit the pom, look for the property that URL points to the jetty-rt-bundles and replace it by the absolute path to where the $your-jetty-rt-bundles/jetty.bundles.repo/target/site is.