Open DorsetDigital opened 5 years ago
I think that's probably more a per-project/per-developer consideration. I'm not sure we should state an explicit preference.
Generally, we've favoured being more relax than not with the recompose command, because that makes it more likely that will be able to upgrade all your packages.
Would an option be a way to deal with it? I'd have thought a stable release would be a safe default, but maybe with the option to use the very latest release by means of a flag in the command line. I'm struggling a bit to think of a typical case where I'd want to routinely upgrade a site from v3 to v4-dev.
At the very minimum, if the behaviour isn't going to change, I think a docs update would be very helpful to explain the situation. Someone who is relatively new to SS4 (and possibly composer) could easily get caught out.
Just had a passing look at the recomposer command. Internally, it calls composer with the --prefer-stable
flag. So it should only try to install a non-stable version of a packages if it can't find a compatible stable release. Are you seeing a different behaviour on your end?
I'll try upgrading another project and see what happens. The last two I did ended up with a dev release of SS4 which I then changed manually during the upgrade process to stable.
I've noticed that the recompose command currently sets up the latest version of recipe-cms, (4.3.3) but doesn't seem to specify a stable release (eg. 4.3.3@stable)
The
create-project
command gives you the stable version, so I'm wondering if the upgrader ought to be consistent with that. Running acomposer update
on a newly upgraded site can leave you with a lot of 'dev' packages! It's obviously a simple thing to deal with when you notice what's going on, but I reckon it would be better to not get to that situation accidentally - the upgrade process can be traumatic enough as it is!