Add automatic publishing to npm

[Acconut]

It would be nice to have auto-publish set up for all of hoodie's projects so we should fetch the latest version directly from npm instead of github. Travis provides a script for that: http://docs.travis-ci.com/user/deployment/npm/

[svnlto]

yes, yes and yes. will be looking at integrating this. If we are going for this tho, we really need to pay attention to semver tho ;) /cc @janl @gr2m @caolan

[janl]

like it.

[Acconut]

Maybe use a grunt plugin? https://github.com/vojtajina/grunt-bump

[svnlto]

@Acconut we use this in hoodie.js not a fan of it, also completely detached from testing / integration tests.

[Acconut]

Since there have been two issues with hoodie-cli which have been fixed in the repo but not been pushed to npm: Any progress on this?

[svnlto]

This wouldn't have fixed the issue as we'd be relying on tags. Which, creating tags needs about the same amount of work as running npm publish

[Acconut]

Ok, that's a good point.

[svnlto]

Let's see how this pans out next time we add a tag.

[Acconut]

Nice, :+1:

[svnlto]

Somewhat related. https://github.com/hoodiehq/hoodie-server/issues/257

[boennemann]

This issue is related to https://github.com/hoodiehq/hoodie-server/issues/257, https://github.com/hoodiehq/hoodie.js/issues/218 and https://github.com/vojtajina/grunt-bump/issues/47 but it's hard to discuss one and the same thing in 3 different spots w/o confusion so I'll try to cover everything related to automated versioning & releases here.

There is consent that versions should be released in a consistent and automated way, so here is my suggested workflow.

grunt-bump

Let grunt-bump take care of the version numbers and a tagged commit.

The concerns regarding grunt-bump are no longer valid, as it is possible (now?) to manipulate and add files between the version bump and the commit. Demo from the docs:

$ grunt bump-only:minor
$ grunt changelog
$ grunt bump-commit

creating tags needs about the same amount of work as running npm publish

I disagree here, because grunt bump also takes care of bower.json or source files. Also it offers an abstraction layer for version numbers with the :major, :minor and :patch flags, so there is even less thinking (read inconsistencies) involved.

I'd configure grunt-bump to automatically push to origin, so there is no way to forget the --tags flag, while doing it yourself.

TravisCI npm deploy

364164f0e7e2aeee177d0064b0ed1e2514ae7eaf is already perfect. What I like about the Travis deploy hook, is that there is no way to accidentally publish a failing build.

Changelog

In my opinion a changelog should come with every release. The easiest way is to generate it from the commit messages, but that requires commit message conventions. I know there are already some in place, but the excellent tools the angular team provides are worth the switch.

type(scope): message e.g. feat(payments): add stripe

1. conventions doc
2. pre-commit validation
3. changelog generator

To v or not to v

Tags aren't necessarily version numbers, so the added unambiguity of a v prefix is a good thing. Can you please elaborate why you'd ditch them?

If there's consent about these things I can take care of implementing them across repos, but first some more discussion \o/

[gr2m]

@boennemann thanks for taking the time and putting it all together! Regarding To v or not to v – I don't care what we do, as long as it's consistent. I have a preference like all of us, but if you're willing to take the responsibility to setup all the things (grunt task, changelog, docs), just go ahead and choose whatever you like, or what is mostly used right now in the repositories.

Thoughts? @caolan @janl @zoepage @svnlto

[svnlto]

thanks for taking the time and putting it all together!

Just as an FYI: npm version {major|minor|patch} adds the v prefix by default..

[janl]

+1

On 13.05.2014, at 00:42, Stephan Bönnemann notifications@github.com wrote:

This issue is related to hoodiehq/hoodie-server#257, hoodiehq/hoodie.js#218 and vojtajina/grunt-bump#47 but it's hard to discuss one and the same thing in 3 different spots w/o confusion so I'll try to cover everything related to automated versioning & releases here.

There is consent that versions should be released in a consistent and automated way, so here is my suggested workflow.

grunt-bump

Let grunt-bump take care of the version numbers and a tagged commit.

The concerns regarding grunt-bump are no longer valid, as it is possible (now?) to manipulate and add files between the version bump and the commit. Demo from the docs:

$ grunt bump-only:minor $ grunt changelog $ grunt bump-commit creating tags needs about the same amount of work as running npm publish

I disagree here, because grunt bump also takes care of bower.json or source files. Also it offers an abstraction layer for version numbers with the :major, :minor and :patch flags, so there is even less thinking (read inconsistencies) involved.

I'd configure grunt-bump to automatically push to origin, so there is no way to forget the --tags flag, while doing it yourself.

TravisCI npm deploy

364164f is already perfect. What I like about the Travis deploy hook, is that there is no way to accidentally publish a failing build.

Changelog

In my opinion a changelog should come with every release. The easiest way is to generate it from the commit messages, but that requires commit message conventions. I know there are already some in place, but the excellent tools the angular team provides are worth the switch.

type(scope): message e.g. feat(payments): add stripe

conventions doc pre-commit validation changelog generator To v or not to v

Tags aren't necessarily version numbers, so the added unambiguity of a v prefix is a good thing. Can you please elaborate why you'd ditch them?

If there's consent about these things I can take care of implementing them across repos, but first some more discussion \o/

— Reply to this email directly or view it on GitHub.

[zoepage]

+1

thank you @boennemann for doing this! <3

[boennemann]

So I'll just interpret this as a "go for it".

I will start w/ hoodie-cli so we can discuss details and then apply it to the rest of the repos.

Fun fact: There is a defined process already: https://github.com/hoodiehq/hoodie.js/blob/master/CONTRIBUTING.md#releasing-a-new-version

[gr2m]

Excellent! Thanks Stephan!