Proposal: Use tags for releases

[cmumford]

I would like to propose that this project create Git tags for each release. As this project is a collection of crates that extend the esp-hal project, adopting its tag naming strategy would be consistent. I propose <package.name>-v<package.version> as esp-hal does. This would result in names like: esp-hal-smartled-v0.15.0 or esp-hal-buzzer-v0.1.0. Tagging the repo is already a recommendation in the cargo book.

In addition to version clarity, reproducibility, etc. this would allow for development to proceed in the main branch for upcoming releases. If it became necessary to create a bug fix release, e.g. esp-hal-smartled-v0.15.1, we could then lazily create a release-branch, maybe named esp-hal-smartled-v0.15.x.

Thoughts?

[cmumford]

I forgot to mention that the impetus for this issue was a PR (#34) with a change for a yet-to-be released esp-hal change.

[jamessizeland]

That sounds very sensible to me

[finalyards]

Noticed this was already done for esp-hal-smartled-v0.16.0 and esp-hal-buzzer-v0.2.0. Great!

Is there something needing to be done, within this issue. e.g. noting down the policy so it will be recorded (i.e. what is the completion criteria for this issue).

[MabezDev]

I believe @robamu did this manually last time, maybe we can get this into a command in the just file?

In fact, my preference would be to allow codeowners to publish themselves, if we can setup the github workflows, I'd be happy to add the required crates.io key to the runner secrets. This can be done at a later date though.

[robamu]

Hmm, it is probably possible to write a script which retrieves the current version from the cargo metadata and then pushes a new tag with that version.. But I usually just do it by hand.