Conversation
mdyoung3
changed the title
Updated document
| 3. Run `drush cim -y` to integrate any config changes from the updated profile. For **VPGE**, please make sure you have any config changes are duplicated and/or applied to the /config/split directory. . | ||
| 4. | ||
|
|
||
| ## 3. Update stanford_profile and dependencies |
There was a problem hiding this comment.
I'm going to do a little re-write on this to iron out some wrinkles. I'll get that in for you on 5/5.
I have updated the VPGE Update document and appended my suggested method for the upstream updates.
|
@mdyoung3 -- I made some extensive additions to the upstream update process. Please review and integrate and/or use it unchanged. |
|
@mdyoung3 -- is this still undergoing updates? I've got a ticket here: https://stanfordits.atlassian.net/browse/VPGE-77 which I'd like to close if we can get this complete. |
|
|
||
| #### `ace-vpgegryphon` | ||
| 1. Create a release branch. | ||
| 2. Update the `composer.json` file to reflect the dev branch of the VPGE profile, and the tagged version of the `stanford_profile` that you pulled in upstream changes. Important: Use the tagged version of `stanford_profile` Using the `11.x` branch may pull in unreleased work which will complicate your process. |
There was a problem hiding this comment.
@imonroe I'm not sure why using 11.x will complicate things. The changes has been reviewed and passed the tests. Tags are just created on the day of deployment.
There was a problem hiding this comment.
Well, consider this situation: Let us suppose we are going to upgrade cardinalsites to drupal 11. It may happen that the stanford_profile 11.x branch composer.json now contains a dependency on drupal/core: ^11. However, if you're working on the VPGE upstream updates, you don't want that yet. You want the dependency to be ^10. If you rely on the 11.x branch instead of the last tagged version of the profile, you're likely to get all kinds of composer conflicts. If it completes the install, you'll still in a situation where stuff throws strange bugs, modules have updated to versions that don't work with the patches, etc. You might have a situation where work has been merged for new stuff, but it's not yet fully implemented. All kinds of things can go wrong.
If you want to use the 11.x branch, I'm not going to stop you, but I very much recommend basing downstream updates on tagged versions, so you have better control over what you're pulling in, reducing the potential for conflicts, and making sure you're only pushing out fully released wok from the upstream. I've tried it both ways, and sticking to the tags is much less headache overall.
There was a problem hiding this comment.
@imonroe If I understand correctly, you're saying some modules wouldn't work with the dependencies in the project route, because they're only compatible with newer versions of Drupal?
It's interesting. My feeling is that maybe Stanford Profile itself should use a new major version for a major upgrade of Drupal 11. That is, it should be Stanford Profile 12.x. Hence people still using Drupal 10 on their stack can grab the latest from 11.x version of Stanford Profile.
That being said, I think it's fine to stick with the latest tagged version. Probably a bit safer.
There was a problem hiding this comment.
Oh, it looks like 12.x will be the new verison.
2 participants
READY FOR REVIEW
Summary
Review By (Date)
Urgency
Steps to Test
Affected Projects or Products
Associated Issues and/or People
@mentionthem here)See Also