Home Explore Help
Sign In
CocoRoboLabs
/
CocoRoboDesktop
3
0
Fork 0
Files Issues 0 Pull Requests 0 Wiki
Tree: 360cac6932
Branches Tags
CocoRoboDesk...
/
pdf1.js
/
node_modules
/
highlight.js
/
docs
/
maintainers-guide.rst

maintainers-guide.rst 1.9 KB
History Raw

12345678910111213141516171819202122232425262728293031323334353637383940414243 
  1. Maintainer's guide
    2. 

  2. ==================
    3. 

  3. 

  4. 

  5. Commit policy
    6. 

  6. -------------
    7. 

  7. 

  8. * Pull requests from outside contributors require a review from a maintainer.
    9. 

  9. 

  10. * Maintainers should avoid working on a master branch directly and create branches for everything. A code review from another maintainer is recommended but not required, use your best judgment.
    11. 

  11. 

  12. 

  13. 

  14. Release process
    15. 

  15. ---------------
    16. 

  16. 

  17. Releases (minor) typically happen on a 6-week schedule.
    18. 

  18. 

  19. For major/minor releases you'll be releasing from ``master``.  For patch releases you'll be releasing from a stable branch, such as ``9-16-stable``.  This allows ongoing development of new features to continue in isolation (in master) without those changes leaking into patch releases (which should focus only on fixing breaking changes).
    20. 

  20. 

  21. The goal being that minor version series always get more stable over time and that patch releases do not add features.
    22. 

  22. 

  23. * For patch releases: First switch to the associated stable branch (i.e., ``9-16-stable``)
    24. 

  24. 

  25. * Update CHANGES.md with everything interesting since the last update.
    26. 

  26. 

  27. * Update version numbers using the three-part x.y.z notation everywhere:
    28. 

  28. 

  29.   * The header in CHANGES.md (this is where the site looks for the latest version number)
    30. 

  30.   * ``"version"`` attribute in package.json
    31. 

  31.   * ``"version"`` attribute in package-lock.json (run `npm install`)
    32. 

  32.   * Two places in docs/conf.py (``version`` and ``release``)
    33. 

  33. 

  34. * Commit the version changes and tag the commit with the version number (``9.16.2``, no "v" prefix or anything like that)
    35. 

  35. 

  36. * For major/minor releases: Create a new ``[major]-[minor]-stable`` branch such as ``9-16-stable``
    37. 

  37. 

  38. * Push the commit and the tags (``git push && git push --tags``)
    39. 

  39. 

  40. 

  41. Pushing the tag triggers the update process which can be monitored at http://highlightjs.org/api/release/
    42. 

  42. 

  43. When something didn't work *and* it's fixable in code (version numbers mismatch, last minute patches, etc), simply make another release incrementing the third (revision) part of the version number.
    44.