search

graphql-kit / graphql-voyager

🛰️ Represent any GraphQL API as an interactive graph
https://graphql-kit.com/graphql-voyager/
MIT License
7.76k stars 514 forks source link

Introducing semantic release #337

Open LunaticMuch opened 1 year ago

LunaticMuch commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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

LunaticMuch commented 1 year ago

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.