Use more standard versions

emteknetnz commented 3 years ago

The approach there to using a self provision + installer rather than a standard provision is correct

Currently most recipes use recipe-cms ^4 instead of a lock-steped version such as 4.x-dev or 4.8.x-dev e.g.

Cow will automatically convert either .x-dev or ^ to the correct stable tag.

update all recipes in cwp-recipe-kitchen sink to change silverstripe/recipe-cms to 4.8.x-dev
on merge-up, change it to 4.x-dev

maxime-rainville commented 3 years ago

The following conclusions were reach from a Slack discussion:

Recipes are meant to work only with specific tags of other recipes.
When cow tags a new recipe release, it lockstep constraint like ^4 to specific tags.
By default, recipes should be tested with self-jobs-range.yml (as opposed to standard-jobs-range.yml) because this build only tries to run the recipe against a specific release line.
- if we don't do that, builds for specific tags will always fail because it will try to install versions that contradict the lockstep.
Recipe composer constraints on dev branches should target what will be lockstep when cow tags the recipe:
- e.g. If recipe-blog 2.8 requires recipe-cms 4.8, then recipe-blog 2.8.x-dev should require recipe-cms 4.8.x-dev
- If we were to use a loose constraint than like `^4', builds would always install the next minor release even if the recipe is lockstep to an older patch release.

maxime-rainville commented 3 years ago

All the PRs have been merged and merged up.

silverstripe / recipe-blog