Skip to main content
Jump to: navigation, search

Stardust/Source Code/Branch strategy

< Stardust‎ | Source Code
Revision as of 04:30, 18 February 2015 by Simone.seurer.sungard.com (Talk | contribs) (Upcoming approach)

(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.

Branches

branch name builds status
b_dev_0_7_1 before stardust 1.0 deprecated
I_4_3 all versions below 2.0 deprecated
I_4_3_SR1 1.1.0 deprecated
I_4_4 2.0 deprecated
I_4_5 - deprecated

Upcoming approach

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 should not work 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. It can happen that Stardust is providing a pure bugfix release for a previous major or minor version as the latest version on master. For instance, in the above picture the master branch contains the version 3.0.0 already. If Stardust would provide a bugfix release, e.g. 2.1.1, then this release will not be merged into the master branch because this would mean that we must also provide a new bugfix release of the current major/minor version.
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 then used to stabilize the current release and to apply changes which are needed for the new Eclipse platform while the development branch is open for further code changes for the next release target.
Release branches
The main purpose of this branch type is to stabilize the final release and if needed to apply all features/changes which must be done to support a new Eclipse platform (this can only happen in new major or minor releases). If we have released the version (typically with RC4) all changes on the corresponding branch are merged into master (if it is the latest Stardust release) and are reintegrated into the development branch. This means that at this point a new Eclipse platform may be supported if the release was part of the simultaneous release. 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.
The release branch is also used to provide minor or bugfix releases. For instance if we have already released the version 2.1.0 but need a bugfix release 2.1.1 then we'll create a new release branch on basis of the 2.1.0 release tag where we continue to develop. This ensures that we don't introduce code changes which were not part of 2.1.0. At this point it can happen that the release branch contains also some milestone builds. If a minor or bugfix release is out then the corresponding release branch will be merged back to the development branch and if the last version on master is less then the current version to the master branch.
Naming pattern: Release branches must be prefixed by the wording release/ followed by the Stardust release version, for instance release/2.1.0.
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.
Naming pattern: Feature branches must start with the wording feature/. Behind the slash you could provide either a short description and/or the Bugzilla ticket number which the feature belongs to. For instance feature/bpmn2-events or feature/Bug-441222 are valid branch names.
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. If you have done this you can merge your changes into the integration branch.
Integration branches
It is not allowed to develop directly onto this branch type. As you can see in the picture we will never merge the changes back to the development branch. This means that all changes would be lost if you push your changes only into this 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. If you have developed a feature on a corresponding feature branch you can merge your changes into the integration branch if it should be part of the parallel build. In this case it would be great if you could announce that in the stardust-dev mailing list so that we're aware of it.
Naming pattern: Branch names of this type starts with integration/ followed by the Eclipse platform name, for instance integration/mars

See also Release Build Plan

Back to the top