Question: Non Semver version support?

[CoreyTrombley]

Before everyone flames me for even asking this. Please just take a moment and breath. I wanted to know everyones thoughts on this. Maybe you can help me convince my work to use semver versions.

I have been tasked with automating our changeloggeneration and versioning. The problem is that we don't use semver for our frontend projects as "There will never be a Breaking Change". I have everything working and all is well except non standard version are not accepted. semver.valid() use here will always return null for our versions (example R20200116.1).

The main reason my company does not want to use semver for our FE project is just what I said before no braking changes. So my ask is... short of forking this package and adding the ability to use any version number, do you have any other suggestions?

Thanks for your time.

[jbottigliero]

Hey @CoreyTrombley! While the semver.valid() check you mentioned will certainly fail, I think you'll find yourself fighting an uphill battle with the rest of the conventional-changelog ecosystem trying to support non-SemVer versions with this library (conventional-recommended-bump and the conventional-changelog-writer come to mind in particular)...

My personal suggestion would be to use SemVer! But I'm probably biased and it's easy for me to say! 😅

As a (kinda gross) workaround, maybe you could appease the no "Breaking Change" crowd and keep something that resembles the format you provided by always tagging as a pre-release (ie. 1.0.0-R{date}.{n})... you'd still have to do a bit of custom tooling, but not quite as much. Or, if the major version bump is the only sticking point, you could provide your own preset that only ever bumps minor and patch.

If SemVer is not an option, you could consider using pieces of the ecosystem to build a utility... the conventional-commits-parser package in conjunction with some custom code to read and write to your version file(s) might be enough to handling version bumping, then you could look to the conventional-changelog-writer for a bit of inspiration on how to generate your CHANGELOG.

All that said, if standard-version's check really is the only thing tripping you up I can look into supporting this, I don't want to dismiss your comment of having "everything working", so let me know!

[CoreyTrombley]

@jbottigliero Thanks for the ideas. So I did end up forking and making it work for our needs. That said, I attempted to get people on board with me by suggesting that very same "kind of ugly" workaround but to no avail. I also don't want to to break the "standardness" of standard-version with a hack for breaking SemVer

If you feel like you still want to add that functionality then huzzah! Thanks again.