index.rst 7.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147
  1. .. _time_boxed_releases:
  2. Release Schedule
  3. ================
  4. Starting with version 2.2 GeoServer releases follow a time boxed model in which releases occur
  5. at regular predictable frequencies rather than at ad-hoc dates. In a time boxed the software is
  6. released at predictable frequencies with whatever fixes, improvements, and feature are available
  7. at the time of release. This differs from the previous feature based model in which releases occur
  8. when a certain number of key features have accumulated.
  9. To compensate for the inherent unpredictability of the release contents the model includes strict
  10. rules about what type of development is appropriate during specific periods of a branches life
  11. cycle. These rules include a suitably long hardening period for the unstable branch to mature and
  12. eventually become stable.
  13. Release branches
  14. ----------------
  15. At any given time GeoServer is undergoing two to three main branches of development.
  16. #. The *stable* branch in which only bug fixing, and smaller scale feature development occurs on
  17. #. The *unstable* (main development branch - main) branch in which more experimental and larger scale feature development occurs
  18. #. The *maintenance* branch which was the previously stable branch that is nearing end of life and sees
  19. only the most stable development, typically mostly bug fixes.
  20. Release cycle
  21. -------------
  22. On the stable branches release follow a monthly cycle in a which a new minor release occurs once a
  23. month. On the unstable branch releases follow a 6 month cycle in which a new major release occurs
  24. once every 6 months. The following diagram illustrates the cycle:
  25. .. image:: timeboxed.png
  26. Things to note:
  27. * monthly releases on the stable branch
  28. * a four month open development period followed by two months hardening period on the unstable branch
  29. * beta releases are supposed to be released out of the unstable series on a monthly basis
  30. across the switch between open development and hardening, followed by the first release candidate
  31. * release candidates are pushed out every two weeks until we reach a stable code base, which will be released
  32. as the new major stable release
  33. * the first release candidate marks the branch off of a new trunk, on which open development starts again
  34. The time of the first release candidate marks the origin of a new stable branch in which the unstable branch
  35. becomes the stable branch, and the stable branches becomes a maintenance branch.
  36. Every month, on the same day, a new release is issued from the stable branch using whatever revision of
  37. GeoServer/Geotools passed the last CITE tests. The release is meant to improve upon the previous release in
  38. both functionality and stability, so unless the project steering committee determines reasons to block the release
  39. it will happen regardless of what bug reports are in Jira. Pending resourcing, they can be fixed in the next release
  40. that comes out one month later.
  41. At any given point in time there are two branches under the development, the stable branch and the main development branch/unstable
  42. branch. Once every six months when the creation of a new stable branch occurs a third active maintenance branch
  43. is created. This branch is kept up to date with the stable stable for a period of one-month after which the final
  44. release on that branch is created. That said there is nothing against a developer continuing to maintain the branch
  45. or creating release from it, it is just not expected.
  46. Development phases
  47. ------------------
  48. The type of development that can occur on a branch is dictated by where the branch is in terms of its life cycle.
  49. Stable branch
  50. `````````````
  51. The type of acceptable development on the stable branch does not change much over its lifetime. It is meant
  52. for bug fixes and new features that do not affect the GeoServer API or significantly affect the stability.
  53. A PSC vote (with eventual proposal) can be called in case a significant new feature or change needs
  54. to be back ported to the stable branch overriding the above rules.
  55. If, for any reason, a release is delayed the next release will be rescheduled 30 days after the last release
  56. (that is, delaying the whole train of remaining releases).
  57. Unstable branch
  58. ```````````````
  59. The type of development on the main development branch/unstable branch changes over its lifetime from four months of open
  60. development to two months of stable/hardening development.
  61. Open development phase
  62. ``````````````````````
  63. The open development phase starts when the new stable release is branched off, and ends when hardening
  64. starts, four months after the new stable release is made.
  65. During this phase developers are free to commit stability undermining changes (even significant ones).
  66. Those changes still need to be voted as GSIP anyways to ensure, as usual, resourcing checks, API consistency
  67. and community review.
  68. After three months from the release of the stable series a first beta will be released,
  69. one month after that the second beta will be released and the branch will switch into hardening mode.
  70. Hardening phase
  71. ```````````````
  72. The hardening phase starts when the second beta is released and continues through all release candidate (RC)
  73. releases. The first RC is released one month after the second beta, and then bi-weekly releases
  74. will be issued until no major issues will be reported by the user base, at which point the last RC
  75. will be turned into the new stable release.
  76. During hardening only bug-fixes and new non core plugins can be developed
  77. Commit rules
  78. ------------
  79. The following are guidelines as to what types of commits can occur in any particular phase. While the PSC
  80. reserves the right to vote and override the committing guidelines the following rules reflect the
  81. current policies.
  82. The **hardening phase**, and by extension the stable and open phases, can receive any of the following
  83. types of commits:
  84. * bug fixes
  85. * documentation improvements
  86. * new plugins contributed as community or extension modules (with a cautionary note that during
  87. hardening the attention should be concentrated as much as possible on getting the new release stable)
  88. In addition the **stable phase** can receive any of the following types of commits:
  89. * new minor core functionality (e.g. new output format)
  90. * new API that we can commit to for a long period of time (provided it's not a change to existing API unless the PSC votes otherwise).
  91. GeoServer is not a library, so defining API can be hard, but any class that can be used by pluggable
  92. extension points should be changed with care, especially so in a stable series
  93. In addition to the above the **stable phase** can receive the following types of changes provided there are no
  94. reservations or concerns about them from the PSC. Such changes may be subject to voting:
  95. * promotion of extensions to core
  96. * core changes that are unlikely to affect the stability of the upcoming release
  97. (if the PSC is ok better land them right after a release to get as a large window for testing as possible)
  98. * back port of larger changes that have proven to be working well on trunk for an extended period of time
  99. During the **open development phase** all types of commits are fair game but of course large changes are still subject to proposals and reviews.
  100. During a Release
  101. ----------------
  102. During a release (on any branch) your cooperation is needed:
  103. * We hold off merging fixes several days prior to release, email if you are approaching this deadline and need help
  104. * To help identify any blockers (an email will be sent out prior to release)
  105. * Help test pre-release artifacts prior to their being published for download
  106. * Keep issue tracker status up to date so the release notes are correct
  107. * Please treat our release volunteers with respect, we know deadlines can be stressful