Closed chillu closed 4 years ago
+1 to this. Agree we should prioritise monitoring errors over testing the demo (which I think is happening okay at the moment).
That was our initial intention however I think we pinned it down to 4.4.1
(1.4.2 as 1.4.1
of admin) as a hotfix for something.
When we remove this lock, we'll need to perform some manual testing one time to make sure it works and not something in the state that only works with cms/4.4.1 on admin/1.4.2
There's a PR for this to update the composer.json
but there's Behat failures as a result of the update. I'm pulling this back into our team's radar to look at.
PR: https://github.com/silverstripe/bambusa-installer/pull/104
Leaving a note here to validate and discuss with the team an assumption that we could use the latest dev
branch rather than stable.
The hypothesis: that could be useful for bambusa users to access the features unreleased, but scheduled for the next stable release (merged upstream)
The outcome: Bambusa demos represent the most up-to-date feature set.
Main PR has been merged and I've tested it works by creating my own demo.
Our intention here was to create a mostly maintenance free demo (no additional steps on our release process), and to force us to treat software releases in a way that we shouldn't be afraid of our product demos running them automatically.
Any objections to pinning the recipe to
^4
, rather than^4.4.1
? This assumes we actively monitor errors, because we don't test this particular combination on our recipe releases there can always be things falling through the cracks. It also assumes that we're OK with the occasional demo user seeing errors, because we don't have time to regression test Bambusa against new releases.ACs:
Pulls request