release.rst 4.3 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091
  1. ====================
  2. Salt Release Process
  3. ====================
  4. The goal for Salt projects is to cut a new feature release every three to
  5. four months. This document outlines the process for these releases, and the
  6. subsequent bug fix releases which follow.
  7. Feature Release Process
  8. =======================
  9. When a new release is ready to be cut, the person responsible for cutting the
  10. release will follow the following steps (written using the 3000 release as an
  11. example):
  12. #. Create first public draft of release notes with major features.
  13. #. Remove any deprecations for the upcoming release.
  14. #. Ensure all required features are merged.
  15. #. Create issue to start the process of deprecating for the next feature release.
  16. #. Run through a manual test run based off of the head of the feature branch.
  17. #. Update all name references to version number in the docs. For example
  18. all neon references in the docs needs to be moved to v3000
  19. #. Review the release notes with major features.
  20. #. Generate the new man pages for the release.
  21. #. Create internal RC tag for testing from the head of the master branch.
  22. #. Build latest windows, mac, ubuntu, debian and redhat packages.
  23. #. Run manual and package tests against new RC packages.
  24. #. Push the internal tag live to salt's repo.
  25. #. Publish release archive to pypi based off tag.
  26. #. Push the RC packages live.
  27. #. Announce new RC to salt-users and salt-announce google groups.
  28. #. Triage incoming issues based on the new RC release.
  29. #. Fix RC issues once they are categorized as a release blocker.
  30. #. Depending on the issues found during the RC process make a decesion
  31. on whether to release based off the RC or go through another RC process
  32. #. If a RC is categorized as stable, build all required packages.
  33. #. Test all release packages.
  34. #. Test links from `repo.saltstack.com`_.
  35. #. Update installation instructions with new release number at `repo.saltstack.com`_.
  36. #. Review and update all impacted :ref:`installation` documentation.
  37. #. Update and build docs to include new version (3000) as the latest.
  38. #. Pre-announce on salt-users google group that we are about to update our repo.
  39. #. Publish release (v3000) archive to pypi based off tag.
  40. #. Publish all packages live to repo.
  41. #. Publish the docs.
  42. #. Create release at `github`_
  43. #. Update win-repo-ng with new salt versions.
  44. #. Announce release is live to irc, salt-users, salt-announce and release slack
  45. community channel.
  46. Bugfix Releases
  47. ===============
  48. Once a feature release branch has been cut from the ``master`` branch, if
  49. serious bugs or a CVE is found for the most recent release a bugfix release
  50. will need to be cut. A temporary branch will be created based off of the previous
  51. release tag. For example, if it is determined that a 3000.1 release needs to occur
  52. a 3000.1 branch will be created based off of the v3000 tag. The fixes that need
  53. to go into 3000.1 will be added and merged into this branch. Here are the steps
  54. for a bugfix release.
  55. #. Ensure all required bug fixes are merged.
  56. #. Create release branch with the version of the release. (ex. 3000.1)
  57. #. Create jenkins jobs that test the new release branch.
  58. #. Run through a manual test run based off of the head of the branch.
  59. #. Generate the new man pages for the release.
  60. #. Create internal tag for testing.(ex v3000.1)
  61. #. Build all release packages.
  62. #. Run manual and package tests against new packages.
  63. #. Update installation instructions with new release number at `repo.saltstack.com`_.
  64. #. Update and build docs to include new version. (ex. 3000.1)
  65. #. Pre-announce on salt-users google groups that we are about to update our repo.
  66. #. Push the internal tag live to salt's repo.
  67. #. Publish release archive to pypi based off tag.
  68. #. Push the packages live.
  69. #. Publish release (v3000) archive to pypi based off tag.
  70. #. Publish all packages live to repo.
  71. #. Publish the docs.
  72. #. Create release at `github`_
  73. #. Update win-repo-ng with new salt versions.
  74. #. Announce release is live to irc, salt-users, salt-announce and release slack channel.
  75. For more information about the difference between the ``master`` branch and
  76. bugfix release branches, please refer to the :ref:`Which Salt Branch?
  77. <which-salt-branch>` section of Salt's :ref:`Contributing <contributing>`
  78. documentation.
  79. .. _`github`: https://github.com/saltstack/salt/releases
  80. .. _`repo.saltstack.com`: https://repo.saltstack.com