Closed brynwhyman closed 3 years ago
It'd be cool if we cool lock it to a dev constraint with a hash maybe (you can do this in composer.json even though it's terrible).
Error we get:
[plan] Invalid version 4.3.x-dev; Please enter a tag in w.x.y(-[rc|alpha|beta][z]) format
Another option is that we could inline aliases in the project composer.json like this:
"require": {
"silverstripe/recipe-core": "4.3.x-dev as 4.2.0"
}
Keen to get your thoughts on this @tractorcow
For context - our team wants to do a CWP alpha release at the end of each sprint containing the work we've completed in that period. Increasingly our team's work is going into core, meaning we often need to be adding the next unstable version of core.
As an aside, it's not necessarily just the core repositories that could benefit from this kind of enhancement, e.g. it's probably fine for us to be tagging alpha CWP recipes but we may not necessarily want to be tagging alpha recipes like silverstripe/recipe-blog
every sprint - if we could define project aliases like this then we could avoid having to do that. I realise that project aliases aren't the best solution here and would make the whole recipe combinations more complicated though
Cow uses custom code to parse and check the constraint:
https://github.com/silverstripe/cow/blob/master/src/Model/Release/Version.php#L60-L73
If we replaced this with https://github.com/composer/semver/ or similar we might have more flexibility for allowing constraints that composer would accept but current cow would not (like ^4.2#abc123de
)
I'd agree with 'use a loose constraint instead of a tag'. i.e. silverstripe/framework: ~4.3.0
but not an explicit dev version (bad practice). Is that ok?
We'd just need to support constraints when setting release version via the plan editor. So if you type out a loose constraint it just uses that "as is" and doesn't try to do an actual release.
That sounds sensible.
@tractorcow FYI we've hit this again, needing to generate changelogs ahead of a core release available and wanting to include all commits to date. It's not currently possible, and would require a dev constraint to be allowed (or ^4.4@dev
or something similar)
We've settled on an approach of tagging a core release candidate immediately prior to the CWP release candidate, and this is much less painful now that both releases are managed by the same team. The sprint-based alpha release cycle hasn't been adopted at this stage, and we have other methods of accomplishing the same objectives. On that basis, I'm going to close this one out.
Currently cow won't allow for CWP to be released if the released core tags haven't been released. E.g we'd need to have a 4.3.0-alpha1 release before we could do a recipe for CWP 2.2.0-alpha1.
This is blocking the team from releasing CWP at the end of each sprint, something that would assist our processes in the lead up to the quarterly stable releases.
This issue covers the change to (from @robbieaverill): modify cow to let us require a dev version of core at a specific hash.