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.
Difference between revisions of "Stardust/Source Code/Branch strategy"
< Stardust | Source Code
m |
(→Upcoming approach) |
||
| (5 intermediate revisions by 2 users not shown) | |||
| Line 10: | Line 10: | ||
* v2.0.0.20140611-1021-GA | * 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. | 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 ==== | ||
| + | {| class="wikitable" | ||
| + | |- | ||
| + | ! 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 [http://nvie.com/posts/a-successful-git-branching-model Gitflow workflow] by Vincent Driessen but with some exceptions resp. extensions. | With Stardust 2.1.0 we want to use a different branching strategy which is similar to the [http://nvie.com/posts/a-successful-git-branching-model Gitflow workflow] by Vincent Driessen but with some exceptions resp. extensions. | ||
| Line 18: | Line 33: | ||
The above picture gives a general overview about the different types of branches. Each branch type will be explained straightaway. Let’s start: | The above picture gives a general overview about the different types of branches. Each branch type will be explained straightaway. Let’s start: | ||
; '''master''' | ; '''master''' | ||
| − | : This branch shouldn’t be used as a development branch which means that committer and contributors | + | : 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''' | ; '''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. | + | : 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 | ; Release branches | ||
| − | : The purpose of this branch type is to stabilize the final release and to apply all features/changes which | + | : 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 [https://wiki.eclipse.org/Simultaneous_Release 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''. | : ''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''' | ; '''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. | + | : 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 [http://bugs.eclipse.org Bugzilla] ticket number which the feature belongs to. For instance ''feature/bpmn2-events'' or ''feature/Bug-441222'' are valid branch names. | : ''Naming pattern'': Feature branches must start with the wording ''feature/''. Behind the slash you could provide either a short description and/or the [http://bugs.eclipse.org 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 [mailto:stardust-dev@eclipse.org stardust-dev] mailing list so that the corresponding committers are aware of it. | + | : ''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 [mailto:stardust-dev@eclipse.org 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''' | ; '''Integration branches''' | ||
| − | : It is not allowed | + | : 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 [mailto:stardust-dev@eclipse.org 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'' | : ''Naming pattern'': Branch names of this type starts with ''integration/'' followed by the Eclipse platform name, for instance ''integration/mars'' | ||
| + | |||
| + | See also [[Stardust/Release Build Plan | Release Build Plan]] | ||
Latest revision as of 05:30, 18 February 2015
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.
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.
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