add information on how to release a new my-first-hoodie version

[gr2m]

I've pushed a new commit: https://github.com/hoodiehq/my-first-hoodie/commit/12b24a5e089caa22f52d248843820034bc454afe. It fixes an issue in hoodie.js, fixed in hoodie@2.1.1.

I don't know how to currently release a new my-first-hoodie version, so it becomes what I get when I do hoodie new myapp. Can we put that information somewhere accessible?

[janl]

We deploy m-f-h manually, like animals:

• run all tests
• update version number in package.json
• commit package.json
• git tag vX.Y.Z
• npm publish
• git push --tags

[gr2m]

isn't the some bundling / shrinkwrap step before publishing? I still don't know how this works exactly, just want to be sure I don't mess up a release :)

[janl]

@gr2m yes, that happens before everything I wrote, like any commits you are making. cc @boennemann for the correct incantations

[boennemann]

The situation here is a bit difficult, I'm hesitant to add anything to the README.md because that's what end users end up with in their newly created app folder. They certainly shouldn't be bothered with instructions for our release process.

So I'm writing this down here and we can then discuss where to put it. There are two parts two it.

When one installs or updates a dependency like npm install --save hoodie@2.1.1 they must run npm shrinkwrap immediately afterwards. That is to make sure that the npm-shrinkwrap.json file is updated. Without this the updated dependency won't be installed/bundled. (With npm@3 that happens automatically)

Manually releasing works like this (assuming clear stage):

1. npm version <major|minor|patch> -m "chore(package): release %s" This updates the version number in both the package.json and npm-shrinkwrap.json, creates a commit with these changes and the passed message and creates a tag.
2. git push origin master --tags
3. npm publish

A note on tests: This repository doesn't have any tests and isn't built on Travis so there is no need for that right now. If you have a manual release process and you'd want to make that tests run you'd define "preversion": "npm run test" in your package.jsons script section. Additionally one should wait for a passed Travis build after 2. before continuing to do 3.

@janl @gr2m

`

[gr2m]

npm version <major|minor|patch> -m "chore(package): release "

There is a %s placeholder for the version, so we can do npm version <major|minor|patch> -m "chore(package): release v%s"

[boennemann]

@gr2m Yeah :+1: The repetition annoyed me as well :D I'll edit it in.

[varjmes]

Would the dot files repo be a good place to put it? I know it's not a 100% fit but it could be good for now. If you end up needing more readies about stuff that don't come bundled with a theme/package/whatever, perhaps a wiki in the future?

[gr2m]

or maybe the wiki of my-first-hoodie?

[boennemann]

Here is my take on this, which might not be that open, but deals with the time constraint we're having till September:

This whole repo will undergo a split into the hoodie-app and hoodie-template thing. Once that's done hoodie-app can have a relevant README.md and automated release process again. I wouldn't want to spend too much time on figuring out a documentation process for this as is. For the time being people who do release can find what they need in this issue.

[gr2m]

:ok_hand:

[janl]

npm version <major|minor|patch> -m "chore(package): release %s" This updates the version number in both the package.json and npm-shrinkwrap.json, creates a commit with these changes and the passed message and creates a tag. git push origin master --tags npm publish

I’d switch this around in the following way:

• npm version
• npm publish
• git push origin master
• git push origin master --tags

That way:

1. if npm publish fails for any reason, the tag isn’t public yet, and you can re-do everything.
2. git push without --tags pushes any outstanding commits that you might still have locally
3. git push with --tags pushes the tag that npm publish created.

It’s the same process, but with a few more common-error-failsaves built in.

[boennemann]

@jan What do you mean by "npm publish fails"? How can it fail, other than the registry being down?

[janl]

@boennemann errors in package.json is what happened to me repeatedly. This will be reduced by the use of npm version, but I can still see scenarios where this could happen, because npm publish publishes the latest version on disk, not the latest commit in git.