Page History

...

Moves provides a facility for creating branches. If you need to branch a project, and if that project might have a release associated with it, then you should use Moves to create a branch.

Branch prerequisites

1. A branch must be created from a release tag. Thus, if you want to create a branch from trunk you should
   1. make sure trunk builds
   2. create a release of trunk (it's ok to do nothing with that release... moves just needs the tag for a branch point)
2. For each dependent component you must decide if you want to create a branch of that component.
   1. If the dependent component does not need to change (ie you are only changing code in your application), there is nothing to do.
   2. If you wish to use the trunk version of the dependent component, then change the version of the dependency in your application back to a range (ie <version>[0.0.0,999.999.999)</version>).
   3. If you wish to use a branch version of the dependent component, then complete these steps for the dependent component, and set up a BRANCH RANGE. (See "Branching Example" below for how to create a dependent branch range).

Branching example.

When should I create a branch?

The answer to this is almost never. Branches add complexity, and changes made to a branch must be applied to the trunk. The process is subject to human error.

Valid reasons for creating a branch include

1. Emergency bug fixes. Suppose you have example-web-app version 1.2.3 on production, and trunk is not in a releasable state. A critical bug needs fixing and you cannot wait until the next scheduled release. In this case you need to
   1. Branch the release on production (1.2.3).
   2. Branch any dependent components that must have code changes
   3. Fix the bugs
   4. Release the branch release
   5. Merge the fix back into trunk
2. Concurrent development. Suppose you have a major change in example-web-app that requires a 6 month developer effort. Meanwhile, the business requires minor enhancements to be released every month. In this case you should create the branch, and apply the minor fixes and releases to that branch.
   1. Merge all branch changes back into trunk frequently.
   2. When the major release is ready, the branch should no longer be worked on.

Branch prerequisites

1. A branch must be created from a release tag. Thus, if you want to create a branch from trunk you should
   1. make sure trunk builds
   2. create a release of trunk (it's ok to do nothing with that release... moves just needs the tag for a branch point)
2. For each dependent component you must decide if you want to create a branch of that component.
   1. If the dependent component does not need to change (ie you are only changing code in your application), there is nothing to do.
   2. If you wish to use the trunk version of the dependent component, then change the version of the dependency in your application back to a range (ie <version>[0.0.0,999.999.999)</version>).
   3. If you wish to use a branch version of the dependent component, then complete these steps for the dependent component, and set up a BRANCH RANGE. (See "Branching Example" below for how to create a dependent branch range).

Branching example.

Let'Let's suppose we have application example-web-app which has version 2.5.3 deployed to production. It depends on edu.mit.ist.es.common:sais-common:3.1.5 (the sais-common component version 3.1.5). Let's suppose it also depends on edu.mit.ist.es.components:example-component:1.2.3 (example-component version 1.2.3). A bug is found in production, and the trunk is not in a releasable state (perhaps we have a bunch of untested changes). We need a release as soon as possible. It is found that the bug fix requires changes to sais-common and -common and example-web-app, but not to example-component.

(In trunk, example-web-app , but not to example-component. (In trunk, is at version 2.6.0-SNAPSHOT, sais-common is at 4.1.2-SNAPSHOT and example-component is at 1.2.4-SNAPSHOT).

The following will need to occur.

1. Use moves to create a branch of example-web-app

...

1. version 2.5.3. (This will become version 2.

...

1. 5.3b1.0-SNAPSHOT

...

1. )
2. Use moves to create a branch of sais-common

...

1. component version 3.1

...

1. .5. (This will become version 3.1.5b1.0-SNAPSHOT)

...

2. Wiki Markup
   Check out the example-web-app branch code (from \[example-web-app-svn-url]/branches/releases/

The following will need to occur.

1. Use moves to create a branch of example-web-app version 2.5.3. (This will become version

   2.5.3b1

   -SNAPSHOT)Use moves to create a branch of sais-common component version 3.1.5. (This will become version

   ).

2. Wiki Markup
   Check out the sais-common branch code (from \[sais-common-svn-url]/branches/releases/3.1.5b1

   -SNAPSHOT

   )

3. Wiki Markup
   Check out the example-web-app branch code (from \[example-web-app-svn-url]/branches/releases/2.5.3b1).

4. Wiki Markup
   Check out the sais-common branch code (from \[sais-common-svn-url]/branches/releases/3.1.5b1).

5. edit the sais-common dependency in example-web-app's pom.xml, so that

   Code Block
   lang xml title Range dependency example
   From: <dependency> <groupId>edu.mit.ist.es.common</groupId> <artifactId>sais-common</artifactId> <version>3.1.5</version> </dependency> To: <dependency> <groupId>edu.mit.ist.es.common</groupId> <artifactId>sais-common</artifactId> <version>[3.1.5b1, 3.1.5b999)</version> </dependency>

6. .

7. edit the sais-common dependency in example-web-app's pom.xml, so that

   Code Block
   lang xml title Range dependency example
   From: <dependency> <groupId>edu.mit.ist.es.common</groupId> <artifactId>sais-common</artifactId> <version>3.1.5</version> </dependency> To: <dependency> <groupId>edu.mit.ist.es.common</groupId> <artifactId>sais-common</artifactId> <version>[3.1.5b1.0, 3.1.5b1.999)</version> </dependency>

Your project should now build and deploy. Moreover, Moves will allow you to select a branch build after you commit all of your changes.

Once the branch has been created, the release process is much like the trunk release process. However, instead of the versions incrementing from, say 1.2.3-SNAPSHOT to 1.2.4-SNAPSHOT, they will increment from, say 1.2.3b1.0-SNAPSHOT to 1.2.3b1.1-SNAPSHOT. This allows you to perform multiple releases on the branch, until the branch cycle is completed. The corresponding released versions will be 1.2.3b1.1, 1.2.3b1.2, 1.2.3b1.3 etcYour project should now build and deploy. Moreover, Moves will allow you to select a branch build after you commit all of your changes.

Screenshots

TODO