Version bump policy

[dominykas]

I'm starting to venture into the dark territory... Either way, as I'll be going through all the buster's submodules and updating their dependencies, I will also be adding this to package.json:

    "engines": {
        "node": ">= 4"
    },

Technically, this is a breaking change, but in practice I'll keep all versions (0.10, 0.12, 4, 5) in .travis.yml and I hope I'll manage to get things working.

Question 1) However, once I'm ready to publish... if pkg is already post-v1, do you think I should bump major, minor or patch or not for such packages?

I know that hapijs folks went as far as simply releasing a new major (v10) as soon as node 4 came out, to note that ES6 will be valid, even though they didn't break anything just then, i.e. they bumped major purely based on intent to break things in the future.

Question 2) As for pre-v1 packages, semver pretty much says "anything goes", so I'll bump minor, unless someone confirms that v1 is in order. I'd appreciate if someone gave me some notes on what's missing for v1 of dependencies (not talking about buster itself [yet]). @dwittner?

Question 3) So far, I've been using 5.x (for post-v1) and 0.5.x (for pre-v1) as a version format for dependencies I'm updating. I use this in my projects and I'd like to also point to hapijs, who use a similar format. I find it a lot clearer than npm's default ~x.y.z or ^x.y.z. I hope there are no objections?

[augustl]

1) I think major should be bumped. If you're on 0.12, you don't expect a upgrade from, say, 1.2 to 1.3 would break your app

2) Agreed, bumping minor makes sense, and also agree that if the module is ready for 1.0 then bumping to 1.0 makes sense too.

3) I like "5.x" and "0.5.x" a lot better so if those specs has semver semantics like ~ and ^ I say go for it!

[augustl]

Update on 1), I'm assuming a engine version requirement on node >=4 would break apps running on node 0.12 upgrading from, say, a version 1.2 without a engine version requirement to a version 1.3 that added a engine version requirement on node >= 4. It's been a while since I've done node hacking so I'm not sure if my assumption is correct :)

[dominykas]

Nope, it doesn't break - only gives a warning during npm install.

[augustl]

I see. If all you get is a warning, then bumping major isn't needed imo since it might be confusing. But if we actually do break stuff on older versions of node, I think we should bump major.

[dominykas]

re question 1 - I'm starting to lean towards bumping major:

• the warning says "node > 4" - someone in the future might just break 0.10 / 0.12 and not bump major, because they might treat the "engine" warning as an actual support note, rather than as a deprecation warning (i.e. it's better to "bump now", to avoid "bump never")
• someone might even add ES6 code, thinking that it's OK, and break 0.10 / 0.12 inadvertantly
• in a lot of cases, I'm actually removing the node 0.6 from travis.yml - and stuff doesn't even work on node 0.8 anymore, so technically I'm making breaking changes
• semver is only as good as you can trust it - some very popular packages are beyond v10 and a there's also a lot which are beyond v5. There's no reason to be afraid to bump major, especially on buster's sub-modules, which are never used outside buster's context
• in a lot of cases I'm updating to when@3 - and that means no more sync promises (no more zalgo!) - that is quite a serious change, so a major bump is in order anyways

Alternatively, I don't really have to add an engines restriction... (which would mean I should republish bane without it).

[dominykas]

Here's what I'm doing so far:

• when I set up travis, I set up 0.10, 0.12, 4.x and 5.x - this means dropping 0.6 and 0.8. This does not warrant a major bump, since I assume that hardcoded 0.6/0.8 mean "latest" - both are gone for a couple of years and everything still works in what was latest for a lot of people for a long time (0.10).
• if a package is pre-V1:
  • bumped multi-glob and ansi-grid to V1 without any changes, except for adding node >= 4 in engines
  • bumped buster-sinon patch level, as it had no changes
  • bumped minors for others and added node >= 4 in engines
• if a package is post-V1:
  • bumped patch, no change in engines, if updates are trivial
  • bumped minor in case of referee as there were new features added (but not published) before dep updates
  • bumped major in case of ramp-resources and posix-argv-parser since both of them depend on when which was updated to v3, which cause quite some havoc - mostly, I only had to change some test setups, and very little code, but a change to no longer release Zalgo in promises was very significant potentially very very breaking. Since I bumped major, I also added node >= 4 in engines.

The remaining unmerged/unfinished updates are all pre-V1 (will bump minor upon release) except for ramp, which is post-V1 and will get a major bump, as it depends on both - when and ramp-resources.

Bumping pre-V1 packages to V1 will be another day's topic once I manage to chew off this whole upgrade thing (and also if I don't break too much, e.g. I intend to try latest buster from git with when and my own projects before releasing anything).