THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
| Warning | ||
|---|---|---|
| ||
I really support this approach, I think it makes the most sense of any of the strategies out there, however the downside of this approach is how it scales over time. As time goes on and the deviation between the functionalities functionalties implemented on the trunk and when they are released increases, the chances of multiple desired functionalities overlapping in some part of the code increases...eventually causing the premature partial release of some functionality. Use of something like that svnmerge.py script that uses svn properties to note what has been merged where and when will address this to some degree, but some system were where we know that F(A) references X files and F(B) references Y files...and when we are looking to promote F(B) but not F(A) we can doublecheck that we are not partially promoting F(A)...since svn merges will not pull out the F(A) changes if they are in the same file as F(B). I see this a lot in volatile development environments coupled with exceedingly tight release cycles. |
...
- A release branch should be made well in advance of the release to allow for stabilzation of the release and the preparation of RCs. A release branch is a long-lived branch from which all the releases for a non-API breaking versions are made. So you would release 2.0, 2.0.1, 2.0.2 of a project from a 2.0.x branch and likewise you would release 2.1, 2.1.1, 2.1.2 from a 2.1.x branch.
- Make sure that all developers checked in their local modifications before the branch is created.
- Copy using URLs as everything will occur on the server and be faster.
To create a release branch to prepare in preparation for a release us use the following command:
| No Format |
|---|
svn copy -m "Create Maven 2.0.x branch" \ svn://svn.apache.org/repos/asf/maven/components/trunk \ svn://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x |
| No Format |
|---|
mvn release:prepare
...
mvn release:perform
...
|
Working on a release branch
...
RCs should be circulated for no less then three days so that we can accurately determine if there are any defects present. When you are ready to release the RC create the tag and then release with use the release plug-in:
...
:
...
| No Format |
|---|
mvn
...
release:prepare
...
...
...
mvn
...
release:perform
...
...
...
| No Format |
|---|
* *TODO* We need to figure out the process of how we tag the RCs, probably don't need to keep them. Maybe just roll over the previous one until the RC is good enough to release.
h3. How to integrate bug fixes into an RC
If bugs are found in the RCs, then the fixes should be applied to the trunk and then it will be up to the release manager to integrate the fixes into the release branch.
* *TODO* Some tag in the SCM message might be useful to give a hint to the release manager, or a tool, as to which revisions need to be merged.
h3. Generating an official release
When you are ready to create a release use the release plug-in:
|
mvn release:prepare
...
mvn release:perform
...
| No Format |
|---|
- TODO We need to figure out the process of how we tag the RCs, probably don't need to keep them. Maybe just roll over the previous one until the RC is good enough to release.
How to integrate bug fixes into an RC
If bugs are found in the RCs, then the fixes should be applied to the trunk and then it will be up to the release manager to integrate the fixes into the release branch.
- TODO Some tag in the SCM message might be useful to give a hint to the release manager, or a tool, as to which revisions need to be merged.
Generating an official release
When you are ready to create a release you need to create a tag and release with the release plug-in:
| No Format |
|---|
svn copy -m "Tag release 2.0.3" \
svn://svn.apache.org/repos/asf/maven/XXX/branches/maven-2.0.x \
svn://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.3
|
| No Format |
|---|
How to integrate bug fixes into a release branch
...