Shards: Do we need version in shard.yml?

[vladfaust]

As far as I understand, a shard's current version is always retrieved from git tags. Maybe we could save a developer's time not bumping shard.yml every time a new, even tiny, change is commited?:

* bump: v0.2.3
* another tiny change
* bump: v0.2.2
* another change
* some change
* bump: v0.2.1
* new non-breaking feature
* bump: v0.2.0

Don't say including version bumps into change commit themselves, it's counter-productive.

If user needs to get an actual version, manual ::VERSION can be maintained by the developer. Or, even better, shards version could be changed to get version from current tag.

WDYT?

Origin: https://github.com/vladfaust/migrate.cr/issues/15

[trans]

I was just thinking about a related issue. When generating a new crystal library layout, it creates a src/{name}/version.cr file. So that is another place the version has to be maintained. Presumably that is to allow the developers to reference the version in code if needed, e.g. display it on command line for {name} -v, or to make conditional code to support different versions of an API. But what if other information might be needed in code, like the description, for example?

Would it be better to have all the spec info available in code, so there is only ever a single source?

[ysbaddaden]

I thought about this: it's redundant and boring.

Yet, we don't only access a shard by its version, but also by refs (commit, branch or another tag), in which case the only solution to properly detect the version is the entry in shard.yml.

Sorry, it's required. Whenever you release a version you MUST have updated the in version shard.yml (and SHOULD update a CHANGELOG file).

Please note that you don't have to release on every fix. Just postpone until you have some fixes. If someone is affected by a bug, she may target a branch or commit to pull them immediately.

[robacarp]

@ysbaddaden perhaps this is an unrelated bug, perhaps it's intentional.

When using @vladfaust's shard linked above, shards never believes its dependencies are up to date. I see this behavior:

$ shards install
#### shards doing its work

$ shards build project
##### shard install happens again

##### shard build executes

While without any dependencies which have mismatched versions, the build command emits 'dependencies are satisfied' and proceeds with the build.

[ysbaddaden]

Yes. The version reported in the Git tag and in shard.yml must be the same. Otherwise the shard can't be installed, checked, maybe even updated, correctly.

[vladfaust]

False, a shard can be installed and updated even with version mismatch (at least when using ‘version:’). An only issue occurs with this satisfying thing which, I thought, could be modified

[RX14]

We should check for mismatch when installing.

[ysbaddaden]

I said correctly. Having a mismatched version in shard.yml vs tag is incorrect.