/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

  1. Release procedure of jEdit
  2. 1. Define a set of requirements for the next stable release.
  3. Discuss and make a list of requirements. The results are put in a
  4. publicly visible file.
  5. (It maybe, TODO.txt in the repository, or a page in Wiki.)
  6. To keep often releases, as a good practice, the requirements must be
  7. readily achievable in some months. If it seems to take more than 3
  8. months, some requirements should be postponed. One major improvement
  9. is enough.
  10. 2. Work on the trunk, to achieve the listed but missing requirements.
  11. Minor improvements or features are also welcome even if they are not
  12. listed as requirements in step 1, unless it slows to achieve the
  13. requirements.
  14. 3. Make a release branch from the trunk. (ex. "/branches/M.N.x")
  15. To keep stabilizing the release, only the following changes are
  16. allowed on the branch.
  17. - Bumping up of the version number.
  18. - Changes under "doc" directory.
  19. - Merging of reviewed changes from the trunk or a separate branch.
  20. See step 5 below for merging.
  21. Anytime after making the branch, the step 1 of the next release can be
  22. started.
  23. 4. Make a public preview build from the branch.
  24. The preview build is announced on jedit-devel, jedit-users,
  25. jedit-announce, with a clear notice saying it is for testing.
  26. For this purpose, daily build can be used. Daily builds are provided
  27. by Eric Berry (elberry), here.
  28. http://www.tellurianring.com/projects/jedit-daily/
  29. 5. Receive bugs for preview builds, and fix them.
  30. Basically, the fixes are first applied on the trunk. If it seems also
  31. good for a release branch, it can be submitted into the Merge Requests
  32. tracker.
  33. http://sourceforge.net/tracker/?group_id=588&atid=1235750&status=1
  34. If a fix can't be applied on trunk (for example, the target code
  35. doesn't exist in the trunk), it can be applied to a separate branch
  36. which is created from the target release branch.
  37. When submitting a merge request, please make sure:
  38. - to mention the complete set of revision numbers which should be
  39. merged
  40. - to set the target branch by "Group"
  41. If a merge request applies to multiple target branches, open separate
  42. merge requests for each target branch and mention the sibling merge
  43. requests in each other.
  44. If a fix can't be merged cleanly by just running "svn merge ...", the
  45. submitter can make another branch (called a backport branch) from a
  46. stable branch to show how it can be merged. In this case, put the
  47. branch name in the merge request.
  48. The merge is done by another committer (reviewer) other than the
  49. original committer of the fix. The fix is accepted only if
  50. - the fix also works for the reviewer, and
  51. - the reviewer is sure that the fix doesn't include unwanted changes
  52. . If a fix was rejected, it can be proposed again with some
  53. refinements made on the trunk or the backport branch.
  54. This means each fix is reviewed by at least two persons. This reduces
  55. possibility of unexpected breakages, and achieves the stability of the
  56. release branch.
  57. During this process, some more preview builds may be made periodically.
  58. 6. If no major bugs are reported against the preview build for the last
  59. period, release from the branch as a stable release. (ex. M.N.0)
  60. 7. After a stable release, bug fix continue as same as the step 5.
  61. If some fixes are merged from the trunk, make a patch release.
  62. (ex. M.N.1, M.N.2, ...)
  63. Please send to jedit-devel@lists.sourceforge.net, if you find any issue
  64. about this procedure.