Release Trains

[janl]

Imagine we commit a fix to hoodie-plugin-api. What needs to be done that the next user that does hoodie new myapp gets that fix?

We should define a process by which an update in a lower-dependecy module propagates to a new release of the high-level modules that are referenced in the user’s apps (e.g. my-frirst-hoodie, hoodie-server and the plugins.

[janl]

cc @boennemann, @svnlto, @caolan do you have any good ideas here? :)

[svnlto]

use my-first-hoodie and manage dependencies via npm, once that's in, all we would need to do it keep my-first-hoodie's package.json up-to-date.

[janl]

@svnlto hoodie-plugin-api is a dependency in hoodie-server, which in turn is a dependency in my-first-hoodie. My question would be, what process/procedure/automation can we set up so that when h-p-a gets a new version, that h-s also gets a new version, so that it can be referenced in m-f-h?

[janl]

As Philip Roberts points out, server will do the trick for us. E.g. all we need is to publish a new version of the sub-dependent module and a fresh npm install will install the latest module version.

That said, not sure how this plays with hoodie cache (@svnlto?)

Finally, and this is the first and biggest actionable item from this, we need to set up, for all modules, the push a tag -> travis -> npm release thinger. (@boennemann can you help with this?)

[boennemann]

I can do the Travis/npm thing for sure. As far as I remember the "main" repos hoodie.js, hoodie-cli, and hoodie-server have this set up already. So basically all the plugins are missing, right? Anything else?
Maybe you could compile a list of packages @janl? Also I'd need to a) be an npm maintainer or b) have a plain-text npm api key, so I don't have to bug you every single time.

As I'm touching all the packages anyways I'd love to take care of the package.jsons a little, by bringing all the dependencies to the latest version, using ^-version ranges consistently and setting up retina-ready badges for at least travis and david-dm.

Regarding cache: Maybe we should change the behaviour to always prefer online versions?

[janl]

@boennemann thanks! I mean all repos on hoodiehq/ that end up in a new shipping app, so there are things like hoodie-plugins-api, hoodie-plugins-manager, node-multicouch, and so on. I’m happy to help compile a definite list. We can definitely make you a maintainer everywhere.

RE cache: how does that work?

[janl]

List:

• [deferred https://github.com/Update browserify, grunt-browserify etc. hoodie#337] hoodie.js
• hoodie-cli
• [deferred] fetch my-first-hoodie template from npm hoodiehq-archive/hoodie-cli#121 my-first-hoodie
  • hoodie-plugin-appconfig
  • hoodie-plugin-email
  • hoodie-plugin-users
  • …
  • hoodie-plugins-manager
  • hoodie-plugins-api
• hoodie-server
• hoodie-pocket-UIKit
• node-multicouch
• couchdb-db-notify
• pocket
• [deferred https://github.com/Update browserify, grunt-browserify etc. hoodiehq-archive/hoodie.admin.js#4] hoodie-admin.js
• local-tld-lib
• node-ports

List maintained by @boennemann

[boennemann]

Thanks for the list.

I'm not quite sure how to handle this for templates like my-first-hoodie. Maybe introduce a hoodie.ignore section in the package.json so the cli can delete .travis.yml, Gruntfile.js etc. But what about the unnecessary devDependencies then? Maybe the template could live in a subfolder of the actual repo, or something like that.

But for the other packages I'll figure out how to do cherry-picks from a different repo, so it should be straight forward :P

for the permissions: https://www.npmjs.org/~boennemann

[janl]

hoodie-cli does the stripping of the my-first-hoodie bits. And IIRC we do npm install --production, so nothing to worry about with devDependencies.

Will set up perms straight away.

[boennemann]

Isn't the git folder the only thing that gets removed? So .travis.yml and package.json with unnecessary devDependencies would still pollute the app folder and possibly confuse users.

Thanks (:

[janl]

@boennemann you are now co-owner of all of the above, except for:

• couchdb-db-notify
• hoodie.admin.js
• hoodie-plugin-stripe

because they are not on npm yet, but you are welcome to add them :)

[janl]

@boennemann then we need to update hoodie-cli to remove the things we don’t need.

[boennemann]

Thanks for the trust, feeling honored (=

I'll look into hoodie-cli then

On Thu, Jun 26, 2014 at 5:19 PM, Jan Lehnardt notifications@github.com
wrote:

@boennemann then we need to update hoodie-cli to remove the things we don’t need.

Reply to this email directly or view it on GitHub:
#46 (comment)

[boennemann]

@janl I guess I'm done for now. All repositories listed and alle core plugins are updated.
Here is a guide on how to set this up: https://github.com/hoodiehq/grunt-release-hoodie/blob/master/SETUP.md
hoodie.js, hoodie-admin.js and my-first-hoodie still depend on other things that'll hopefully be resolved in the near future.

[janl]

Absolutely amazing, thank you so much! :) ❤️ 👍

[boennemann]

🎉