Problems with releasing hubot 3.0

To be clear, I’m not talking about what a hubot 3.0 would look like, just the problems we’d have about releasing 3.0.

Currently, the hubot script generator includes a dependency like:

  "peerDependencies": {
    "hubot": "2.x"
  },
  "devDependencies": {
    "chai": "^2.1.1",
    "coffee-script": "1.6.3",
    "grunt": "^0.4.5",
    "grunt-cli": "^0.1.13",
    "grunt-contrib-watch": "~0.6.1",
    "grunt-mocha-test": "~0.12.7",
    "grunt-release": "~0.11.0",
    "hubot": "2.x",

I’d need to do some more research about peerDependencies, but my initial take would be that off the back any script generated since we starting using packages would be broken or really confused with a hubot-3.x.x package. That’s one part of it.

Then there’s a question of how to handle hubot versions in scripts. Should scripts be taylored to one version? Can they be written tightly enough to work on multiple versions? What type of friction is the greater community going to run into?

cc @bhuga because he was mulling about something for a hubot 3.0, and I was like “funny you should say that…”

cc @michaelansel because we have talked in the past about being (overly) conservative about major version releases

[technicalpickles]

https://github.com/hubotio/evolution/pull/4 is best place to track that. It does have notes on testing a new hubot, but there isn’t a specific list yet for upgrading.

This is a rough idea, but I think it’d go like:

• npm install --save hubot@next
• run the same for any of the hubot external scripts you use that are in the hubotio org
• for any other external scripts, submit a PR to update package.json to be like https://github.com/hubotio/hubot-rules/blob/87b2683b8f74e6fc85b5a9d752d6c15e9496ca67/package.json#L26 (ie ">=2 <10 || 0.0.0-development"

[technicalpickles]

This did actually happen, so closing 🎉