Please publish a 1.0.0

[timoxley]

I think this has reached 1.0.0-worthy.

The current 0.0.x versioning is also a slight PITA because npm install --save tmp will save an exact version, rather than using the user's designated semver prefix e.g. ~ or ^.

[Jackyjjc]

+1 we want to use this library but no 1.0 major version means we might pull in breaking changes if we use ~ or ^?

[raszi]

In Node.js v5.10.0 they included the fs.mkdtemp() and the fs.mkdtempSync() functions.

So my plan is to wait till the file counterparts will arrive as well and then I will refactor the code to use the new methods in the new Node.js versions and then publish the 1.0.0.

[silkentrance]

@raszi I don't know whether using the node provided API is a good choice: https://github.com/nodejs/node/issues/6142#issuecomment-208219259

Some users might have different use cases that might break with the naming scheme implemented in glibc and for which the node provided API is a small wrapper for.

[ioquatix]

Even if the internal implementation changes, the external API is the same. That's fine for a 1.0.0 release.

[silkentrance]

Would you @timoxley @ioquatix be cool with dropping support for node <4.0.0? #108

[ioquatix]

Yes

[timoxley]

@silkentrance No problems with me. Supporting current LTS & LTS-1 is a good policy given the predictable release cadence. Users stuck on <4.x can still depend on node-tmp 0.x.

[silkentrance]

@raszi How about a 1.0.0 release, dropping support for node < 4.0.0. I'd be willing to revise the code and test cases where necessary and update all dependencies accordingly.

[raszi]

Well, I would love to keep the package as much backward compatible as possible but it seems that it is harder and harder day by day.

My other pr with the coverage #107 is failing because the tools are not supporting Node below 0.10.

Dropping 0.6, 0.8, 0.10, and 0.12 seems a bit too large step if I look at this graph.

[timoxley]

Why isnt it enough for users on older nodes use older versions of this package?

[raszi]

@timoxley well yes, that is an option.

[binki]

Regardless of whether or not you’re settled on a good API or not, as long as you plan to have a stable API at all and release bugfix releases, you need to bump up to 1.0.0. If you want to get a perfect API, you can always do that in 2.x. You don’t have to break API before bumping the major ;-).

If you do npm install --save tmp, the generated dependency looks like "tmp": "0.0.31", meaning that if you release a bugfix release, packages won’t get the bugfixes. However, if your version was 1.x, npm install --save tmp would yield a dependency like "tmp": "^1.0.4" meaning that the consuming package could receive bugfix non-API change releases without needing to be modified. You can’t benefit from semver if you stick with 0.x because npm ignores semver for 0.x packages. (This gotcha of npm is documented here). This is why I’ve decided to completely forego publishing anything as 0.x in all of my personal module development. You can see that the default initial version suggested by npm init is even 1.0.0, probably for this reason.

Because tmp is an 0.x package, if I use a third party module that uses tmp, I can’t benefit from fixes in tmp until that third party module is updated because I don’t control that third party module. So, please consider releasing 1.x sooner, and perhaps without making it a “big deal”/breaking change.

[silkentrance]

@raszi since the package is now fairly stable, including also the fix for #115, I'd like to propose the following:

• first, publish 0.0.32 as soon as the branch gh-115 is merged into master
• second, bump version to 1.0.0 and make that the node 0.x .. < 4.x (including 6.x and 7.x) package all fixes regarding the old version will go into revisions thereof we would need to (back)port any bug fixes going into that release
• third, bump version to 2.0.0 and make that the node >=4.x package, dropping support for node <4.x altogether

I know that there is a problem with npmjs.org that will replace the most current release by the latest one being published, but they might have a solution for that already.

What do you think?

[raszi]

Sounds like a good plan. I need to review again what is the usage of the old node versions because just for the sake of simplicity at our end I don't want to sacrifice the experience of users on old node versions.

[silkentrance]

I have asked over at npmjs whether they gather data such as to which node version is used when installing the required packages. However, they do not seem to collect such data. So sad :trumpet:

[silkentrance]

A 0.1.0 version has been committed to the repository.

[silkentrance]

For builds run on appveyor, support for node < 4.0.0 has already been dropped. Working on making this happen before new years' eve.

[silkentrance]

for reference #108

[silkentrance]

This has been succeeded by #158, follow the discussion there.