/jEdit/tags/jedit-4-5-pre1/doc/release-procedure.txt
# · Plain Text · 88 lines · 64 code · 24 blank · 0 comment · 0 complexity · 424799fece8d4cce62381f41afce2872 MD5 · raw file
- Release procedure of jEdit
-
- 1. Define a set of requirements for the next stable release.
-
- Discuss and make a list of requirements. The results are put in a
- publicly visible file.
- (It maybe, TODO.txt in the repository, or a page in Wiki.)
-
- To keep often releases, as a good practice, the requirements must be
- readily achievable in some months. If it seems to take more than 3
- months, some requirements should be postponed. One major improvement
- is enough.
-
- 2. Work on the trunk, to achieve the listed but missing requirements.
-
- Minor improvements or features are also welcome even if they are not
- listed as requirements in step 1, unless it slows to achieve the
- requirements.
-
- 3. Make a release branch from the trunk. (ex. "/branches/M.N.x")
-
- To keep stabilizing the release, only the following changes are
- allowed on the branch.
- - Bumping up of the version number.
- - Changes under "doc" directory.
- - Merging of reviewed changes from the trunk or a separate branch.
- See step 5 below for merging.
-
- Anytime after making the branch, the step 1 of the next release can be
- started.
-
- 4. Make a public preview build from the branch.
-
- The preview build is announced on jedit-devel, jedit-users,
- jedit-announce, with a clear notice saying it is for testing.
-
- For this purpose, daily build can be used. Daily builds are provided
- by Eric Berry (elberry), here.
- http://www.tellurianring.com/projects/jedit-daily/
-
- 5. Receive bugs for preview builds, and fix them.
-
- Basically, the fixes are first applied on the trunk. If it seems also
- good for a release branch, it can be submitted into the Merge Requests
- tracker.
- http://sourceforge.net/tracker/?group_id=588&atid=1235750&status=1
-
- If a fix can't be applied on trunk (for example, the target code
- doesn't exist in the trunk), it can be applied to a separate branch
- which is created from the target release branch.
-
- When submitting a merge request, please make sure:
- - to mention the complete set of revision numbers which should be
- merged
- - to set the target branch by "Group"
-
- If a merge request applies to multiple target branches, open separate
- merge requests for each target branch and mention the sibling merge
- requests in each other.
-
- If a fix can't be merged cleanly by just running "svn merge ...", the
- submitter can make another branch (called a backport branch) from a
- stable branch to show how it can be merged. In this case, put the
- branch name in the merge request.
-
- The merge is done by another committer (reviewer) other than the
- original committer of the fix. The fix is accepted only if
- - the fix also works for the reviewer, and
- - the reviewer is sure that the fix doesn't include unwanted changes
- . If a fix was rejected, it can be proposed again with some
- refinements made on the trunk or the backport branch.
-
- This means each fix is reviewed by at least two persons. This reduces
- possibility of unexpected breakages, and achieves the stability of the
- release branch.
-
- During this process, some more preview builds may be made periodically.
-
- 6. If no major bugs are reported against the preview build for the last
- period, release from the branch as a stable release. (ex. M.N.0)
-
- 7. After a stable release, bug fix continue as same as the step 5.
- If some fixes are merged from the trunk, make a patch release.
- (ex. M.N.1, M.N.2, ...)
-
-
- Please send to jedit-devel@lists.sourceforge.net, if you find any issue
- about this procedure.