Hey @jdrouet, thanks for this. Is this a replacement for just publishing to crates.io? Could we also make it publish a version tag?

Hey @jdrouet, thanks for this. Is this a replacement for just publishing to crates.io? Could we also make it publish a version tag?

It should generate version tags, readmes and publish to crates.io. The complete process.

To make this work, we need to follow the first 2 steps from this doc. This will add a secret token that will allow this new action to publish the new release to crates.io.

Hi @jdrouet, this looks promising. Are you willing to followup with the remaining steps and demonstrate how to create the next VRL release?

Sorry for the late reply.

Nice, I agree this looks promising. A couple of questions:

• Would this let us delete some of the release scripts currently in scripts/?

I think, we should let release-plz do everything, not use custom things, so yes, we should delete those scripts.

• It seems like this publishes on every push to main. Do we want that?

No, it's more magic than that. It will run on every commit on the main branch to generate a new release PR but it will release only when merging that release PR. (Here is an example or here a simpler one)

In that release PR, it will update the changelog, update the version of the package according to the semantic versioning stuff. You can modify the PR if you don't agree with the picked version or if you wanna change the changelog.

• Agreed with @pront that we should document this. I'd suggest doing so in the README

Could you clarify what you would expect in the readme?
If we want to use this, we should:

• make sure we have a crates.io token set in the github-action configuration
• create the release-plz action in our workflow
• check that it properly creates the release PR
• merge the first one to create a release. If it doesn't work, we can still release it manually.

But first, we could also try using the release-plz binary locally to see if it works properly with VRL (never done that locally, I always go rogue on the CI for my project, but I understand we cannot do that here).

To conclude this, if we merge this PR, it will not release VRL. It will create a PR (or update the existing one) each time we merge something in the main branch. And IF and ONLY IF, we merge that PR, it will release the package (creating the release in github and publishing it in crates.io).

After discussing with @pront and @jszwedko , the way the changelog is generated was brought. In conclusion, we should disable the changelog generation.

After the direct discussion we had, I think we can close this for now