Locking down shards

[jwoertink]

When working on a Lucky project, you may have your own custom shards and need to run shards update somewhat often. Since shards doesn't give us the ability to update a very specific shard, we run the risk of updating any other shards not locked in place.

For the most part, this isn't much of an issue; however, we did run in to this when Crystal 0.29.0 was released. Lucky has a dev dependency ameba. When running shards build (which may happen from running a task), the dev dependency is called. more info. In this case, the latest ameba was installed which only supported Crystal 0.29.0, but people running Lucky 0.14 on Crystal 0.28.0 now had a borked app.

One thing I do even in other languages is to lock working 3rd party libraries to a very specific version. ~> 0.10.0 says it's ok to use 0.10.X where X could be any version number. This does not guarantee us that the shard maintainer won't introduce breaking changes from 0.10.1 to 0.10.2.

I propose that any shard (dev dependency or not) that is not within the Lucky org be locked to very specific working versions. This can be a little more restrictive, but ensures that when running shards update in your project, you won't accidentally update something you're not ready for. So if we know that everything works with Ameba 0.10.0, then we define it as

development_dependencies:
  ameba:
    github: veelenga/ameba
    version: 0.10.0

If there was any new features we needed, or security updates in those shards, we can create a new PR to test that nothing breaks for us by updating to that new version.

These are the shards I found that could use a locked version.

• https://github.com/luckyframework/lucky/blob/master/shard.yml#L61
• https://github.com/luckyframework/lucky_cli/blob/master/shard.yml#L12
• https://github.com/luckyframework/lucky_cli/blob/master/src/generators/web.cr#L160
• https://github.com/luckyframework/avram/blob/master/shard.yml#L14
• https://github.com/luckyframework/avram/blob/master/shard.yml#L19
• https://github.com/luckyframework/avram/blob/master/shard.yml#L21
• https://github.com/luckyframework/lucky_flow/blob/master/shard.yml#L12
• https://github.com/luckyframework/carbon/blob/master/shard.yml#L16

[paulcsmith]

100% agree! I did that for a few a couple commits ago but I think you’re right we should do it for everything. You’re reasoning and examples are spot on

…

On Jun 14, 2019, at 5:47 PM, Jeremy Woertink ***@***.***> wrote: When working on a Lucky project, you may have your own custom shards and need to run shards update somewhat often. Since shards doesn't give us the ability to update a very specific shard, we run the risk of updating any other shards not locked in place. For the most part, this isn't much of an issue; however, we did run in to this when Crystal 0.29.0 was released. Lucky has a dev dependency ameba. When running shards build (which may happen from running a task), the dev dependency is called. more info. In this case, the latest ameba was installed which only supported Crystal 0.29.0, but people running Lucky 0.14 on Crystal 0.28.0 now had a borked app. One thing I do even in other languages is to lock working 3rd party libraries to a very specific version. ~> 0.10.0 says it's ok to use 0.10.X where X could be any version number. This does not guarantee us that the shard maintainer won't introduce breaking changes from 0.10.1 to 0.10.2. I propose that any shard (dev dependency or not) that is not within the Lucky org be locked to very specific working versions. This can be a little more restrictive, but ensures that when running shards update in your project, you won't accidentally update something you're not ready for. So if we know that everything works with Ameba 0.10.0, then we define it as development_dependencies: ameba: github: veelenga/ameba version: 0.10.0 If there was any new features we needed, or security updates in those shards, we can create a new PR to test that nothing breaks for us by updating to that new version. These are the shards I found that could use a locked version. https://github.com/luckyframework/lucky/blob/master/shard.yml#L61 https://github.com/luckyframework/lucky_cli/blob/master/shard.yml#L12 https://github.com/luckyframework/avram/blob/master/shard.yml#L14 https://github.com/luckyframework/avram/blob/master/shard.yml#L19 https://github.com/luckyframework/avram/blob/master/shard.yml#L21 https://github.com/luckyframework/lucky_flow/blob/master/shard.yml#L12 https://github.com/luckyframework/carbon/blob/master/shard.yml#L16 https://github.com/luckyframework/lucky_cli/blob/master/src/generators/web.cr#L160 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[jwoertink]

closed by all those PRs