Support semver config option to control how versions are bumped #41
Conversation
|
I think this is not the right module to change the version in the |
|
This doesn't change the version in package.json. It decides how to set the version for your maven artifact based on your semver incrementing instructions for package.json's version. |
|
This isn't necessarily intended to have people bumping the major/minor versions of their maven artifacts separately from their package.json versions. It's more to allow passing the params to semver (which was already being used to do patch bumps on snapshots) to allow control to set the version of your maven artifact. More specifically I needed prerelease components for my snapshots in one case As well, I do my release management version bumping in a different order than what was expected before, since it used to patch bump the version for snapshots, but not for releases. Meaning if your package.json version was 1.0.1 then your maven artifact would be 1.0.2-SNAPSHOT, or 1.0.1 for releases. But I wanted 1.0.1-SNAPSHOT and 1.0.1 instead. With this PR you can pass in the semver params for full control of your maven version number instead of having to change the package.json version to exactly what you want (which isn't what your npm published version necessarily uses). I think having to change my package.json version to 1.0.1-alpha-3 before a mvn deploy and then change it back would be really weird. Or even having to do the same work to on the version just so you can pass it into conf.finalName directly. |
|
@micha149 have you gotten a chance to take a closer look at things and why this is needed? |
|
Sorry, I was on vacation the last weeks. I am still not sure if dealing with versions should be part of this module. For this reason I am also surprised that we have already a dependency to semver, for this "-SNAPSHOT" feature. How can we know which versioning schema a project uses? This is not always semver… In my opinion we have to drop the Or just merge this PR and give a shit on „what is the actual purpose of this module?” … |
|
I still think semver provides value for the purpose it's being used for here. So depending on how you set up your build system your versions in package.json may not match what you want your maven versions to be. However, you will likely want the versions correlated, and this is where I think semver is useful. Without semver you'd have to mess with the version string to get what you want (exactly what semver does). This PR allows controlling the transformation that semver uses instead of having it oppionated as to what version should be published to maven. As well, this means you can add other qualifiers to the version which you couldn't do before unless it was part of the npm version as well. Getting around the weird isSnapshot semver inc was part of what I was trying to do, so I can see removing it altogether and forcing people to set the version directly. Otherwise, the current semver stuff can provide some convenience so people don't have to do as much manual work in the common case. |
Adding a new 'semver' config option that can take the semver release type to bump the package.json version before being used to create artifacts.
I needed to specify prerelease components for my versions, as well this should fix #38 too.
I set this up to be backwards compatible (ie there's no version changes for releases and a patch bump for snapshots), so it should be completely invisible off the bat. Otherwise it gives you lots of control to change the version number, and tries to be smart by converting any prerelease components over to maven qualifiers.