Please release v1 and start using semver

[jedwards1211]

I just merged some PRs to jscodeshift-add-imports and jscodeshift-find-imports to silence peer dependency warnings on jscodeshift. We decided to set the peer dep version to "jscodeshift": ">=0.7 <1", which isn't great, but it seems like the only reasonable thing we can do if we're not going to update the peer dep every time jscodeshift releases a new 0.x version.

Aside from the fundamental problems with using 0.x versioning on a widely used library, it's not even clear from the changelog here if there are any breaking changes from one 0.x version to another. I can't tell what the rationale for bumping the minor or patch version number is here.

In any case, having >=1.x semantic versioning would reduce the friction for library authors and end users in dealing with future changes to jscodeshift.

Releasing a v1 doesn't have to mean you're declaring jscodeshift stable or unlikely to have breaking changes soon. You could officially disclaim that in the README. It would just be a promise that future 1.x versions (if you do release any before 2.x) have no breaking changes.

[Daniel15]

Version 1.0 would imply that it's a brand new thing, but jscodeshift has been around for a long time and is long past the stage when a 1.0 should have been released. In reality, we'd likely promote the minor version to a major version like React did (the next version after React 0.14.0 was React 15.0.0). We can do that in the next release.

if there are any breaking changes from one 0.x version to another. I can't tell what the rationale for bumping the minor or patch version number is here.

Generally with semver, for versions less than 1.0, minor versions should be treated like major versions (e.g. 0.14.0 to 0.15.0 is a minor change), and patch versions should be treated like minor versions.

[jedwards1211]

Yeah that would be good!

Generally with semver, for versions less than 1.0, minor versions should be treated like major versions (e.g. 0.14.0 to 0.15.0 is a minor change), and patch versions should be treated like minor versions.

This may be a convention, but:

• looking at jscodeshift's changelog, it seems like the minor number has been bumped several times when there were no breaking changes
• All that the semver spec says is that "Anything MAY change at any time", so to be safe users have to assume 0.14.0 to 0.14.1 could have breaking changes unless a project specifically says otherwise

Version 1.0 would imply that it's a brand new thing

I think it's fine if you skip 1.0 but I want to emphasize that since semver doesn't specify this meaning, it isn't the case unless a project clearly says so. When people hold onto outside assumptions about version numbers, it can make an ecosystem function less smoothly. For example, 0.x versioning is rampant in Rust, and if you search for why, it's because there's a culture among Rust devs of thinking 1.0 implies a high level of stability. As a consequence, users have to consult changelogs more often than would be necessary.

I think spreading clearer thinking about versioning (version numbers have no meaning beyond what is explicitly specified) is important to help make the ecosystem more secure and convenient. In a project that has hundreds of dependencies and thousands of transitive dependencies, it would be a nightmare to try to stay up to date with the latest security fixes and improvements if most packages weren't using >=1.0 semantic versioning -- you'd be spending a significant portion of your time just reading changelogs.

[Daniel15]

it seems like the minor number has been bumped several times when there were no breaking changes

Some of these were because dependencies were bumped to a new major version, as that can cause breakages in apps that use jscodeshift too.

[Daniel15]

Released v17.0.0 which resolves this issue. v1.0.0 didn't feel right given jscodeshift has been around for nine years.

[jedwards1211]

Awesome, thank you!