nlf · September 15, 2014 21:25
diff --git a/gistfile1.txt b/gistfile1.txt
 The question has come up a few times as to how releases are handled in the hapi ecosystem, so I'm going to explain hopefully all of it here for everyone. Let me know if there are questions.

 The primary release tracking comes from github milestones. There must always be a milestone representing the next version to be released. For sanity's sake, it's assumed that the next version will be a patch release (i.e. if 6.7.0 is released the new milestone created will be "6.7.1"). If it's determined later that the new version should be a major or minor, edit the milestone's title and the paper trail is maintained. When a version is released, mark the milestone as closed and make a new milestone for the next version (i.e. "6.7.2"). This makes sure that when a release is made the milestone accurately documents all of the changes that were made as a result of that version.

 Every change in functionality or bug fix must have an issue associated with it, and the commit related to the issue should mention the issue number (for example, put "for #35" or "closes #35" in your commit message). Those issues, as I'm sure you've guessed, must also be associated with the milestone representing the next release.

 Along with being documented in github issues, this also allows us to use the tool mdchangelog to automatically create and maintain a CHANGELOG.md.

 So the release process checklist goes like this:

 Make sure any issues that are still open are not associated with the current milestone
 Mark the current milestone as closed
 Run mdchangelog --no-prolog --no-orphan-issues --overwrite from the root of your project and commit the new CHANGELOG.md
 Run npm version [major|minor|patch] to increment the version in your package.json and automatically create a new commit and tag (make sure the new version matches the milestone you just closed)
 Run git push origin master && git push origin --tags
 Run npm publish
 Create a new milestone representing the next version to be released (increment the patch level)
 For versioning, we stick to strict semantic versioning. If you just fixed a bug, that's a patch. If you added a feature without changing existing ones, that's a minor. If you changed how something works (from the user's perspective), that's a major.

 If this process is followed it means that every single version of the package that is ever released has both a milestone and a tag associated with it, so going back to retrieve specific versions or seeing what changed for a version is extremely simple.
	The question has come up a few times as to how releases are handled in the hapi ecosystem, so I'm going to explain hopefully all of it here for everyone. Let me know if there are questions.

	The primary release tracking comes from github milestones. There must always be a milestone representing the next version to be released. For sanity's sake, it's assumed that the next version will be a patch release (i.e. if 6.7.0 is released the new milestone created will be "6.7.1"). If it's determined later that the new version should be a major or minor, edit the milestone's title and the paper trail is maintained. When a version is released, mark the milestone as closed and make a new milestone for the next version (i.e. "6.7.2"). This makes sure that when a release is made the milestone accurately documents all of the changes that were made as a result of that version.

	Every change in functionality or bug fix must have an issue associated with it, and the commit related to the issue should mention the issue number (for example, put "for #35" or "closes #35" in your commit message). Those issues, as I'm sure you've guessed, must also be associated with the milestone representing the next release.

	Along with being documented in github issues, this also allows us to use the tool mdchangelog to automatically create and maintain a CHANGELOG.md.

	So the release process checklist goes like this:

	Make sure any issues that are still open are not associated with the current milestone
	Mark the current milestone as closed
	Run mdchangelog --no-prolog --no-orphan-issues --overwrite from the root of your project and commit the new CHANGELOG.md
	Run npm version [major\|minor\|patch] to increment the version in your package.json and automatically create a new commit and tag (make sure the new version matches the milestone you just closed)
	Run git push origin master && git push origin --tags
	Run npm publish
	Create a new milestone representing the next version to be released (increment the patch level)
	For versioning, we stick to strict semantic versioning. If you just fixed a bug, that's a patch. If you added a feature without changing existing ones, that's a minor. If you changed how something works (from the user's perspective), that's a major.

	If this process is followed it means that every single version of the package that is ever released has both a milestone and a tag associated with it, so going back to retrieve specific versions or seeing what changed for a version is extremely simple.