New command: release

[miketheman]

When developing a library, it is convenient to have a method of releasing a version with well-known semantics, such as version tagging and github push.

In Ruby's Bundler, it is common to use rake release which performs a few actions, including a push to the remote rubygems.org site.

While Crystal Shards don't yet have a "release" location, a command like shards release from a working directory of a shard could validate that the current state is safe, tag the version, and push to github.

[duraki]

Any update on this?

[jkthorne]

rake release mostly just tags and pushes to rubygems.com right?
would we want shards release to do anything more?

[miketheman]

@wontruefree I'd take that as a starting point. I think it does a "git push --tags" as well - to ensure that the tag actually makes it to the remote.

[straight-shoota]

I don't think this makes any sense as a shards subcommand. shards shouldn't care about how you release your shard. There is no one-size-fits-all solution.

It is much easier to use a customized Makefile or CI script for a release process.
Maybe #202 could provide a way to integrate a custom release script into shards CLI.

[caspiano]

Having a shards release command makes sense to me.
As shards uses semver and the reference is pulled from version control tags, it's a pretty limited surface to manage... but the operations happen enough that it seems routine for me, and worthy of a tool enhancement.

Something like shards release <major|minor|patch> that updates the shard.yml and attempts to tag the current commit with the updated version would be handy IMO.

[z64]

Almost since I have started using Crystal , I have constantly run into shards that are improperly configured:

• v missing from tag (UX: Shards requires tags to start with "v" #521)
• version in shard.yml mismatching tag version, because they forgot to update it
• Nothing to do with shards, but similarly the convention of MyShard::VERSION gets out of sync as well

It is not fun when it goes unnoticed, and you need to open a back & forth with the maintainer to resolve it. I end up needing to switch to a fork temporarily (or commit pinning), then switch back once its fixed.

---

Shards should really help people get this right. I think it is fine if shards does not want to "release" code, but the very least, I would suggest a shards tag command that would

• Read the version in shard.yml
• Ensure the version is well-formed per spec
• Create a well-formed tag
• This would fail if the tag already exists

This would help encourage people to edit shard.yml first, and ensure the tag is created correctly.

There could be shortcuts:

shards tag major
shards tag minor
shards tag patch

that would take the current version and bump the respective version field, further reducing the possibility of mistakes. It would assume semantic versioning, and fail otherwise, but I think that is fine: 99.9% of shards use basic, semver versioning.

shards tag {version}, which would ensure shard.yml version matches before creating that tag. Or update shard.yml with that version for you. It would tolerate v or no-v, and make sure the tag starts with v.

Then users can take care of pushing, or whatever their distribution channel is, without needing shards / shards imposing any pipeline.

[straight-shoota]

The other day I read this introduction blog post for cargo dist: https://blog.axo.dev/2023/02/cargo-dist

A basic building block for that is cargo release which seems to work quite well. Cargo has a centralized registry where the release can be published to with cargo publish. That Crystal doesn't have, but publishing would just mean to push the tag to the public repository. So maybe this could be available as a convenience feature in a single step as well.