Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

THyM/Development


THyM
Website
Download
Community
Mailing ListForumsIRCmattermost
Issues
OpenHelp WantedBug Day
Contribute
Browse Source



Getting Started

Getting the Code

  • Clone your fork
   $ git clone git@github.com:<you>/thym.git
   $ cd thym
   $ git remote add upstream git@github.com:eclipse/thym.git
 

At any time, you can pull changes from the upstream and merge them onto your master. The general idea is to keep your 'master' branch in-sync with the 'upstream/master'.

   $ git checkout master               # switches to the 'master' branch
   $ git pull upstream master          # fetches all 'upstream' changes and merges 'upstream/master' onto your 'master' branch
   $ git push origin                   # pushes all the updates to your fork, which should be in-sync with 'upstream'


  • Create a topic branch based on master, Please avoid working directly on the master
  $ git checkout -b my_contribution
  • Make changes for the bug or feature.
  • Make sure you have added the necessary tests for your changes.
  • Make sure that a full build (with unit tests) runs successfully.
  • Commit your changes and have your commit messages in the proper format

For Example:

   [410937] Auto share multiple projects in single job
   
   When multiple projects are imported together, perform all the necessary
   auto shares in a single job rather than spawning a separate job for each
   project.
   
   Bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=410937
   Also-by: Some Otherperson <otherperson@someplace.net>
   Signed-off-by: Joe Somebody <somebody@someplace.net>

Note that the "Signed-off-by" entry is required see Development_Resources/Contributing_via_Git

  • You can then push your topic branch and its changes into your public fork repository:
   $ git push origin my_contribution         # pushes your topic branch into your fork

And then generate a pull-request where we can review the proposed changes, comment on them, discuss them with you, and if everything is good merge the changes right into the official repository.

Setting up IDE to contribute to THyM

We recommend using and enabling the following plugins in IDE: JDT, PDE, EGit and GitHub connectors

In order to resolve the various dependencies of THyM, you can find some target-definition files on the Git repository, under top-level folder target-platforms. Import the target-platforms folder in your workspace and open the current main .target file (if there are more than one, see on parent pom the value of target-platform property which references the main one). Upon opening, the target content will be downloaded. When complete, you can press the Set as Target Platform link in the top right corner to update the target platform. PDE will then load the content of the target file, so it will be all set to resolve the various dependencies of THyM.

Bugs and enhancement requests

Builds

Project can be built and tested locally with a simple mvn clean verify.

The is a Hudson instance for the project that hosts a few builds. See https://hudson.eclipse.org/thym/ . Job https://hudson.eclipse.org/thym/job/THyM/ builds continuously and publishes the latest snapshot build from latest Git revision at http://download.eclipse.org/thym/snapshots

Promotion and Release process

The technical part of the release process is done in 2 steps, only by people who have been granted permission to carry it on. Those permissions are defined in Jenkins jobs by givin Run power to those who can drive the release process.

  1. Promote the latest build as staging version running https://hudson.eclipse.org/thym/job/promote-build-to-staging/ . This will populate the http://download.eclipse.org/thym/staging area with content of the latest CI build (from https://download.eclipse.org/thym/snapshots ). This target location will not be altered unless you re-run the job. It can then be considered as stable enough for testing purposes.
  2. Community test the staging version at http://download.eclipse.org/thym/staging . If it fits to the expectation for the release, then
  3. Promote staging as release running https://hudson.eclipse.org/thym/job/promote-staging-to-release/ . You'll be asked to set a RELEASE_NAME, this is a mandatory text that should be the name of your release (such as 0.1.0, 0.2.0, 1.0.0, 1.0.1....). If you set RELEASE_NAME to 0.2.0, then URL of the release will be http://download.eclipse.org/thym/releases/0.2.0 . There is also a IS_LATEST parameter: if set to true (default) then the location http://download.eclipse.org/thym/releases/latest also gets populated with the content of the staging repository.
  4. Once you're done with moving content, send an announce mail to inform of the new release, sum up the main change, link to change log, and thank contributors.

Release Plan

See Release Plan

Back to the top