silverstripe / cow

Release tool for Silverstripe CMS
BSD 3-Clause "New" or "Revised" License
6 stars 8 forks source link

Allow CWP to be released without core tags #99

Closed brynwhyman closed 3 years ago

brynwhyman commented 6 years ago

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.

robbieaverill commented 6 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"
}
robbieaverill commented 6 years ago

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

robbieaverill commented 6 years ago

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)

tractorcow commented 6 years ago

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.

robbieaverill commented 6 years ago

That sounds sensible.

robbieaverill commented 5 years ago

@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)

Cheddam commented 3 years ago

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.