Skip to content

Latest commit

 

History

History
218 lines (138 loc) · 12.3 KB

target_platforms_releases.adoc

File metadata and controls

218 lines (138 loc) · 12.3 KB
Raw

Maintaining target platforms

Target-platforms use local mirror of our dependency

In order to ensure we always have access to our dependencies, all of them are mirrored on download.jboss.org since external provider don’t have some real lifecycle and sustainability for their sites. This is usually done through an Ant file invoking p2.mirror task, and then the site gets pushed manually to download.jboss.org. Those Ant files to produce mirror are available in the jbosstools-download.jboss.org repository

So in order to add a new dependency to the target-platform definition, first make sure to mirror it on download.jboss.org.

Publish …​

Publishing has its own process. This process is implemented on Jenkins, but it could be achieved manually.

…​ "Multiple" Target-Definitions to Nexus

First run

cd jbosstools/unified
mvn deploy

then the multiple target-definition will become an artifact on JBoss Tools Nexus repository. In case you’re publishing a release, you’ll need to go to Nexus and access the staging repository and promote it as a release.

…​ "Unified" site to download.jboss.org

From the build of the multiple target platform is deduced a unified p2 repository that contains all the content of the unified target (ie all the dependencies of JBoss Tools). This site can be found after a build of multiple target in the multiple/target/multiple.target.repo folder.

Then the content of this site is pushed to download.jboss.org for consumption by component builds and end-users (in case of a release). Publishing is achieved by this script The generated unified site is generally published as a subfolder of http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/ .

…​"unified" target-definition to Nexus

Once the site is ready and available, we can generate the "unified" target that will reference all the content of this site. This is simply achieved by a mvn deploy.

Releasing process

Although we’re free to work with SNAPSHOTs, it’s necessary to communicate when we release a new Target-Platform and make it default. Having a target-platform released implies a few additional steps before and after publishing.

Here is the suggested process:

Before the release:

  1. Build and publish a SNAPSHOT (can be done with jbosstoolstargetplatform-matrix & jbosstools-centraltarget_master job on Jenkins)

  2. Compare content of newer SNASPSHOT of target platform site with previous version, using p2diff. Keep track of the changes that were not announced earlier and send a mail with a summary of those changes. Such changes can be some refactorings inside features, that are not visible directly in the .target file.

  3. Announce on mailing-list the "release candidate" -SNAPSHOT and ask them to test the SNAPSHOT as a "release candidate". This can be achieved by running builds with the following flag -Dtpc.version=<snapshot-to-test>

  4. Change component CI jobs and parent pom for the work-in-progress branch to use this snapshot, setting -DTARGET_PLATFORM_VERSION=<snapshot-to-test> or -DTARGET_PLATFORM_VERSION_MAXIMUM=<snapshot-to-test> in Maven execution

  5. Gather feedback

    • if something is wrong, fix it and restart from #0

  6. After enough time, send mail to the mailing-list saying that we’re in the process of releasing the new target-platform

  7. Remove -SNAPSHOT from all target-platforms pom files.

    $ mvn -Dtycho.mode=maven versions:set

  8. Commit it, tag it; push tag and commit to the right branch:

    $ git add pom.xml pom.xml */*/pom.xml
$ git commit -m "Version 4.90.0.Final"
$ git tag 4.90.0.Final
$ git push origin 4.90.0.Final
$ git push origin HEAD:4.90.x
    (where 4.90.0.Final has to be replaced by the actual version, and 4.90.x with the actual branch)

  9. Repeat the 2 previous steps for jbosstools-discovery component to update and tag its target-platform.

  10. Update jbosstoolstargetplatform-matrix job to build new SNAPSHOTless version (and therefore produce new update site folders) (eg., 4.90.0.Final-SNAPSHOT → 4.90.0.Final)

Note
 (TODO: Try to make the version a job parameter to change it more easily)

  1. Run the CI jobs to publish new versions.

  2. Verify everything is correct on staging repo, plus published jbosstools/devstudio target platform update sites on download.jboss.org & www.qa

  3. Go to Nexus[http://repository.jboss.org/nexus] and promote the target-platforms as release. (See https://community.jboss.org/wiki/MavenDeployingARelease)

After the release:

  1. Update affected pom files to point to the new release of target-platform (for stable branch) or the new snapshots (for master). Example of affected pom files are jbdevstudio-product/pom.xml (for central zip location),

  2. Update affected jobs to point explicitly to the new target platform versions (ref: JBIDE-13673)

  3. Update relevant SNAPSHOT of parent pom so this new target becomes a default where we want it to be default (most likely on next branch for milestone if already available)

  4. Bump target-platform version and add it a -SNAPSHOT to start working on future version.

    $ mvn -Dtycho.mode=maven versions:set -DnewVersion=x.y.z.qualifier-SNAPSHOT
$ git add pom.xml */pom.xml */*/pom.xml
$ git commit -m "Bump to x.y.z.qualifier-SNAPSHOT"
$ git push origin <branch>

  5. Update target-platform job on Jenkins to build the new SNAPSHOT (eg: 4.90.0.AM1 → 4.90.0.AM2-SNAPSHOT)

Leverage Akamai for better download perforance

In order to improve the installation time for a user, it’s recommended to move the aggregated repository for a RELEASED (ie not SNAPSHOT) target-platform to Akamai. Akamai is enabled in the 'static' folder of download.jboss.org/tools, so publishing to Akamai is mainly a matter of moving stuff around.

Here’s a Jenkins job that handles the move into the 'static' folder, then symlinks from the old path to the new one.

Manual method:

First, ssh mount a file system from download.jboss.org, then:

Then, check with Eclipse or p2diff or whatever p2 tool that location http://download.jboss.org/jbosstools/targetplatforms/${name}/#{version}/ can resolve TP contents.

Announce release

Using the template below will get you started, but you will still need to fill in these details:

  • changes since previous target platform release

  • specify if this is a Central target platform release, or a jbosstools/devstudio target platform release. Often these are not released at the same time, as Central updates at a slower cadence than jbosstools/devstudio.

For examples of previous change notification emails, see:

Note that this step is often omitted, but is still useful from a notification point of view.

You might want to create a new job to automate these notifications.

Template:

# configure these to generate the email body
TARGET_PLATFORM_VERSION=4.90.0.Final # no -SNAPSHOT suffix
TARGET_PLATFORM_VERSION_NEXT=4.90.1.AM1-SNAPSHOT # include -SNAPSHOT suffix
JBOSSTOOLS_VERSION=4.9.1.Final       # no -SNAPSHOT suffix
JBOSSTOOLS_VERSION_NEXT=4.9.2.AM1    # no -SNAPSHOT suffix
JBOSSTOOLS_BRANCH=master

echo "
Subject:

Target Platform ${TARGET_PLATFORM_VERSION} for JBoss Tools ${JBOSSTOOLS_VERSION} has been released.

Body:


Changes
=======

* (TODO: copy these from proposed change notification emails)


Usage
=====

Target platform ${TARGET_PLATFORM_VERSION} is what JBoss Tools ${JBOSSTOOLS_VERSION} will use.

All Jenkins jobs for branch ${JBOSSTOOLS_BRANCH} and parent pom ${JBOSSTOOLS_VERSION}-SNAPSHOT
have been updated to use target platform ${TARGET_PLATFORM_VERSION}.

The following p2 repositories *will be modified* to point to this new target platform once
JBoss Tools ${JBOSSTOOLS_VERSION} is released:

* http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/
* https://devstudio.redhat.com/targetplatforms/devstudiotarget/

(TODO: include this next one if this is a Central TP update, not a jbosstools/devstudio TP update)

* http://download.jboss.org/jbosstools/targetplatforms/jbtcentraltarget/

Until then, you can access the target platform at the URLs below.


Download
========

Update site: http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/${TARGET_PLATFORM_VERSION}/REPO/

Update site zip: http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/${TARGET_PLATFORM_VERSION}/jbosstoolstarget-${TARGET_PLATFORM_VERSION}.zip

Git tag: https://github.com/jbosstools/jbosstools-target-platforms/tree/${TARGET_PLATFORM_VERSION}


Testing/Development
===================

If your root pom correctly specifies the latest parent pom version as ${JBOSSTOOLS_VERSION}-SNAPSHOT, you need only this:

  $ mvn clean verify

If you're using a different parent pom, use this:

  $ mvn clean verify -Dtpc.version=${TARGET_PLATFORM_VERSION}

For advanced usage and help (using in IDE, building a mirror locally, using a zip), see:

* link:target_platforms/target_platforms_for_consumers.adoc[Using Target Platforms]


What's next?
============

jbosstools-target-platforms project branch 4.90.x has been prepared for potential upgrades, and its version is now ${TARGET_PLATFORM_VERSION_NEXT}.  We can at least expect for Beta3:
* [[ Examples of highly probably changes, update them ]]
* Move to Luna release/R/SR0
* Re-introduction of a compatible version of Birt
* Shall you need anything else, please follow those instructions to request a change ASAP: https://github.com/jbosstools/jbosstools-devdoc/blob/master/building/target_platforms/target_platforms_updates.adoc
 Deadline for changes in target platform 4.90.0.Beta4-SNAPSHOT is *Monday, June 30th*


All Jenkins jobs for *master* and parent pom ${JBOSSTOOLS_VERSION_NEXT}-SNAPSHOT
have been updated to use target platform ${TARGET_PLATFORM_VERSION_NEXT}.
"