ReleaseChecklist.txt

Pre-release checklist:

  [ ] Update the documentation as necessary (in docs/)
  [ ] Update CHANGELOG.md with features included in the new release
  [ ] Update README.md with latest version number
     [ ] Update the docs URL if the minor version has changed
     [ ] Update sbt example in README.md with latest version
     [ ] Update "latest release" sentence in README.md with latest version
     [ ] Update "Major changes in ..." section in README.md
        [ ] Add the features listed in CHANGELOG.md to the "Major changes in ..." section
  [ ] Remove the "-SNAPSHOT" from the version** in Default.scala
  [ ] Remove the "-SNAPSHOT" from the version** in ThriftCodegenPlugin.scala
  [ ] Bump thriftCodegenVersion in Default.thriftBootstrap to the LAST released version
  [ ] Reload sbt
  [ ] Run "; +all/clean; +all/test" in sbt to make sure everything works.
  [ ] Run "+publishable/publish-local"
  [ ] Commit these changes (but don't push!)

Release checklist:

  [ ] Run "+publishable/publish" in sbt
  [ ] Find the spindle repository on oss.sonatype.org / Staging Repositories
  [ ] Select it and click Close
  [ ] Select it and click Release

Post-release checklist:

  [ ] Tag the release version (e.g., "git tag v1.0.0")
  [ ] Bump the MINOR version** in Default.scala and add "-SNAPSHOT" to it
  [ ] Bump the MINOR version** in ThriftCodegenPlugin.scala and add "-SNAPSHOT" to it
  [ ] Commit these changes
  [ ] Push both commits to Github
  [ ] Push tags to Github with "git push origin --tags"
  [ ] If the minor version has changed, go to Admin > Versions on readthedocs.org/projects/spindle and check the box
      next to 'Active' for the new version


[** A note about version numbers:

    When choosing version numbers, we should follow the Semantic Versioning 2.0.0 Specification
    
    From http://semver.org/

        SUMMARY:

        Given a version number MAJOR.MINOR.PATCH, increment the:

        MAJOR version when you make incompatible API changes,
        MINOR version when you add functionality in a backwards-compatible manner, and
        PATCH version when you make backwards-compatible bug fixes.
        Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

    In general, the "master" branch (that is, most new development) should have a MINOR version
    increment from the previous released version. Only if incompatible changes are planned should
    a MAJOR version increment be necessary. PATCH version increments should only be released for
    bugfixes specifically backported to a previous MINOR version release.
]