You can not select more than 25 topics Topics must start with a chinese character,a letter or number, can include dashes ('-') and can be up to 35 characters long.

RELEASE_CHECKLIST.txt 4.9 kB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170
  1. # Release checklist:
  2. ## Pre-release tasks
  3. * Figure out whether a release is worthwhile to do.
  4. * Analyze the previous release branch to see if anything should have been
  5. applied to master.
  6. * Collect changes and assemble tentative release notes.
  7. * Identify previous release branch point
  8. * Check commit logs between previous branch point and now for
  9. notable changes worth mentioning
  10. * Create a new issues_closed_for_X.Y.md file
  11. * Include notable entries from here in the release notes.
  12. * Analyze APIs between previous release branch and master to produce list of
  13. changes (added/removed/updated funcs, etc...), and detect backwards compat
  14. issues.
  15. * https://github.com/lvc/abi-compliance-checker
  16. * If the new release is not backwards compatible, then this is a MAJOR release.
  17. * Mention removed features in ChangeLog
  18. * Consider re-adding backwards compatible support, through symbol
  19. aliases and appropriate entries in json-c.sym
  20. * Update the AUTHORS file
  21. git log -r 31ab57ca..HEAD | grep Author: | sed -e's/Author: //' ; cat AUTHORS ) | sort -u > A1
  22. mv A1 AUTHORS
  23. * Exclude mentioning changes that have already been included in a point
  24. release of the previous release branch.
  25. * Update ChangeLog with relevant notes before branching.
  26. * Check that the compile works on Linux - automatic through Travis
  27. * Check that the compile works on NetBSD
  28. * Check that the compile works on Windows - automatic through AppVeyor
  29. ## Release creation
  30. Start creating the new release:
  31. release=0.15
  32. git clone https://github.com/json-c/json-c json-c-${release}
  33. mkdir distcheck
  34. cd distcheck
  35. # Note, the build directory *must* be entirely separate from
  36. # the source tree for distcheck to work properly.
  37. cmake -DCMAKE_BUILD_TYPE=Release ../json-c-${release}
  38. make distcheck
  39. cd ..
  40. Make any fixes/changes *before* branching.
  41. cd json-c-${release}
  42. git branch json-c-${release}
  43. git checkout json-c-${release}
  44. ------------
  45. Using ${release}:
  46. Update the version in json_c_version.h
  47. Update the version in CMakeLists.txt (VERSION in the project(...) line)
  48. Update the set_target_properties() line in CmakeLists.txt to set the shared
  49. library version. Generally, unless we're doing a major release, change:
  50. VERSION x.y.z
  51. to
  52. VERSION x.y+1.z
  53. git commit -a -m "Bump version to ${release}"
  54. If we're doing a major release (SONAME bump), also bump the version
  55. of ALL symbols in json-c.sym.
  56. See explanation at https://github.com/json-c/json-c/issues/621
  57. More info at: https://software.intel.com/sites/default/files/m/a/1/e/dsohowto.pdf
  58. ------------
  59. Generate the doxygen documentation:
  60. doxygen
  61. git add -f doc
  62. git commit doc
  63. ------------
  64. Create the release tarballs:
  65. cd ..
  66. echo .git > excludes
  67. tar -czf json-c-${release}.tar.gz -X excludes json-c-${release}
  68. echo doc >> excludes
  69. tar -czf json-c-${release}-nodoc.tar.gz -X excludes json-c-${release}
  70. ------------
  71. Tag the branch:
  72. cd json-c-${release}
  73. git tag -a json-c-${release}-$(date +%Y%m%d) -m "Release json-c-${release}"
  74. git push origin json-c-${release}
  75. git push --tags
  76. ------------
  77. Go to Amazon S3 service at:
  78. https://console.aws.amazon.com/s3/
  79. Upload the two tarballs in the json-c_releases folder.
  80. When uploading, use "Standard" storage class, and make the uploaded files publicly accessible.
  81. Logout of Amazon S3, and verify that the files are visible.
  82. https://s3.amazonaws.com/json-c_releases/releases/index.html
  83. ===================================
  84. Post-release checklist:
  85. git checkout master
  86. Add new section to ChangeLog for ${release}+1
  87. Use ${release}.99 to indicate a version "newer" than anything on the branch:
  88. Update the version in json_c_version.h
  89. Update the version in CMakeLists.txt
  90. Update RELEASE_CHECKLIST.txt, set release=${release}+1
  91. Update the set_target_properties() line in CmakeLists.txt to match the release branch.
  92. git commit -a -m "Update the master branch to version 0.${release}.99"
  93. git push
  94. ------------
  95. Update the gh-pages branch with new docs:
  96. cd json-c-${release}
  97. git checkout json-c-${release}
  98. cd ..
  99. git clone -b gh-pages https://github.com/json-c/json-c json-c-pages
  100. cd json-c-pages
  101. mkdir json-c-${release}
  102. cp -R ../json-c-${release}/doc json-c-${release}/.
  103. git add json-c-${release}
  104. git commit -a -m "Add the ${release} docs."
  105. vi index.html
  106. # Add/change links to current release.
  107. git commit -a -m "Update the doc links to point at ${release}"
  108. git push
  109. ------------
  110. Update checksums on wiki page.
  111. cd ..
  112. openssl sha -sha256 json-c*gz
  113. openssl md5 json-c*gz
  114. Copy and paste this output into the wiki page at:
  115. https://github.com/json-c/json-c/wiki
  116. ------------
  117. Send an email to the mailing list.