Introducing semantic release

[LunaticMuch]

The management of releases for voyager is actually flaky. The version of the package does not follow commits merged into main and the publishing of the releases is not aligned with new changes introduced.

Idea is to introduce a solution, e.g. semantic-release to ensure that release versioning is done by default when a merge in main is realised, and, also, there's an easy way to rebuild npm package.

To be supercautious, I will make few tests and publish the package under my scope in npm @LunaticMuch/graphql-voyager.
There will be no intent to have a second distribution line.

I will introduce semantic-release into my fork, create a changelog and move from there.

[IvanGoncharov]

@LunaticMuch Thanks I agree with above points.
However, I personally dislike semantic-release tool.
I wanted to use something like this: https://docs.github.com/en/actions/publishing-packages/publishing-nodejs-packages#publishing-packages-to-the-npm-registry

[LunaticMuch]

I missed this. Let me have a look, I am not sold to semantic release.

[LunaticMuch]

I see your point now @IvanGoncharov - My idea with semantic versioning was less for publishing to npm (which of course, you can do), but rather for having automatic version management changelog within the repo.
The publishing on npm registry can be done on demand and not being necessarily related to the version in the repo.
However, I think it's beneficial to have correct versioning (semantic versioning or any common approach) for the main branch.