Inject latest loco version insdead of *

[kaplanelad]

In the CLI, we generate the Cargo.toml with the following dependency:

loco-rs = { version = "*" }

Replacing the asterisk (*) with the currently running version is advisable to mitigate potential breaking changes in the master branch.

Related issue: #85

[kaplanelad]

I have reservations about whether this issue will address the underlying problem.

The loco-cli currently fetches the template from the master branch. If the code in the starter template is more up-to-date, it doesn't matter how loco-rs is defined, the build will brake.

Consider adopting a workflow like a dev branch and merging into master exclusively during the release of a new library version. This approach may provide a more effective solution.

[jondot]

I did some thinking --
I think the best solution is to create a "mono repo like" versioning system.

All crates, all CLIs, all projects "move forward" together and are locked to a version
This is what works well in hyperstackjs.io.

There is one additional scenario, where people are happy with what they generated, and don't want to upgrade.
If they DO want to upgrade, they come with their version, and look for a changelog to see what breaking changes they have to fit
(which means we also need a changelog)

[kaplanelad]

That sounds like a good suggestion.
I have created a xtask that will support pre-release and will do it automatically. #104

so the flow will be:

• lock all the starters to loco lib version.
• Run bump-release xtask will replace that do
  • change loco lib to the given version
  • change starters to the new given version

Then, you just need to commit the changes, merge them, and publish the crate.