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

Stardust/Source Code/Branch strategy

< Stardust‎ | Source Code
Revision as of 10:47, 23 October 2014 by Sven.rottstock.fisglobal.com (Talk | contribs) (Created page with " == Up to Stardust 2.0.1 == Up to Stardust 2.0.1 we have used one branch for each Eclipse platform (Kepler, Luna, Mars etc). This means that we have created a corresponding in...")

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Up to Stardust 2.0.1

Up to Stardust 2.0.1 we have used one branch for each Eclipse platform (Kepler, Luna, Mars etc). This means that we have created a corresponding integration branch as soon as the first simultaneous release build was planned.

CurrentStardustBranchingStrategy.png

For instance branch I_4_4 was used by the developers to push their changes that should be included in the Stardust releases which are part of Eclipse Luna (4.4.0, 4.4.1 aka SR1 and 4.4.2 aka SR2). After each Stardust milestone and RC build we have tagged the sources which were used by the build with the following tag format: v<stardust-version>.<build-timestamp>-<alias>. stardust-version points to the official announced Stardust version like 2.0.1. The alias flag identifies either the corresponding milestone or release candidate. Furthermore it could also be used to identify the GA release. The following examples shows possible tags for each release phase:

  • v2.0.0.20131218-0600-M4
  • v2.0.0.20140522-0247-RC2
  • v2.0.0.20140611-1021-GA

If we have released a Stardust version, all changes which was done up to the GA tag were merged into the master branch. As you can see in the picture above a further integration branch for the next Eclipse platform could be created in the meantime. So if we have merged the changes from an integration branch into master, we have also merged these changes into all branches for upcoming Eclipse platforms.

Upcomimg approach (draft)

With Stardust 2.1.0 we want to use a different branching strategy which is similar to the Gitflow workflow by Vincent Driessen but with some exceptions resp. extensions.

UpcomingStardustBranchingStrategy.png

The above picture gives a general overview about the different types of branches. Each branch type will be explained straightaway. Let’s start:

master
This branch shouldn’t be used as a development branch which means that committer and contributors are working on it resp. push their changes to it. Rather only released Stardust versions are merged into this branch. This has the advantage that new contributors who’re cloning the Stardust repos have a stable branch with the latest features.
development
Committers/Contributors should use the development branch to include bugfixes or bigger changes to the code line which are target for the next Stardust release. With beginning of the RC release phase a separate branch will be created on basis of the current development state. This branch is used to stabilize the release and to apply changes which are needed for the new Eclipse platform.
Release branches
The purpose of this branch type is to stabilize the final release and to apply all features/changes which are needed to support a new Eclipse platform. If we have released the version (typically with RC4) all changes on the corresponding branch are merged into master and are reintegrated into the development branch. This means that at this point a new Eclipse platform may be supported. In the picture above you’ll see that with the merge of the release/3.0.0 branch the Eclipse platform is changed to Mars on development and master.
Feature branches
This branch type is used if you want to apply a huge change or if you have changes which are target for a new Eclipse platform as the one which is used on the development branch. Each feature branch must contain a single topic. So it is prohibited to mix various features on the same branch. The time of life of such branches depends on when the feature will be integrated into the development or release branch. If it is merged into one of them then the feature branch should be deleted. In the picture above feature/y was branched from development and after the feature is completed and merged into development the branch is deleted. The same happens with feature/x but this branch is merged into the release branch at this time. If you like you can merge the latest changes from the development branch from time to time into your corresponding feature branch.
Note: If you develop a feature which should be integrated into a newer Eclipse platform as the one of the development branch, please announce this to the stardust-dev mailing list so that the corresponding committers are aware of it.
Integration branches
It is not allowed for non-authorized Committers/Contributors to push their changes into this branch type. As you can see in the picture we will never merge the changes back to the development branch. The purpose of this branch type is to perform parallel builds which can occur if Eclipse starts a new release train (platform) which we want to participate. For each milestone build we will merge the latest source code from development and announced feature branches into the integration branches.

Back to the top