Gar
``` > semver.inc('3.2.4-pre.1', 'premajor') '4.0.0-0' ``` It seems we also drop the existing preid, unlike ``` > semver.inc('3.2.4-pre.1', 'prerelease') '3.2.4-pre.2' ```
Draft PR at https://github.com/npm/node-semver/pull/752
> That's confusing. I would submit that this is a product of design, and unavoidable. Prerelease is not very intuitive and a lot of folks stumble here. The use case...
How do you make sure the new pre-release is a new version and not the same one as before?
I think you'll need to show an example cause that's either the current incorrect behavior or the other incorrect behavior (re-using versions) we're trying to avoid. Let's say we're in...
To put it another way: we need semver itself to be able to do the correct thing here. We've found that without fail if folks try to hand-roll this logic...
> from 10.1.0-pre.0 to 10.1.0-pre.1 is prerelease (not preminor) It's also preminor! That's the argument we're making here. The `10.1.0-pre.0` is already in preminor. so asking for preminor *again* should...
in this example ``` 9.1.0 semver -i preminor 9.1.0 // we need a small fix 9.2.0-0 semver -i prerelease 9.2.0-0 // wip 9.2.0-1 semver -i prerelease 9.2.0-1 // wip 9.2.0-2...
> I see these use cases: You are forgetting d) our release process is automated and we need to be able to tell semver what to do from two pieces...
> premajor in one call will bump the version up to the next major version and down to a prerelease of that major version. preminor, and prepatch work the same...