Skip to content

Instantly share code, notes, and snippets.

@pawlik
Last active December 8, 2015 07:50
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save pawlik/e1b15aa10f8da3bdb5c3 to your computer and use it in GitHub Desktop.
Save pawlik/e1b15aa10f8da3bdb5c3 to your computer and use it in GitHub Desktop.
Proposal: include additional step to our release action plan: "composer update"
I would suggest to after step:
"Move incremental configs"
to add step:
"run composer update" and push to master.
Arguments:
- composer update is fairly safe since we moved to explicit versions
- doing so will give us 2 weeks evaluation before next release
(both when developing and when PO evaluates new release candidate)
And most of all:
there's not other way to resolve conflicts in composer.lock than to run `composer update`.
Now updates appear ad-hoc when it's needed, so those end up in random feature branch.
This leaves it to PO discretion and feature quality when it's merged into main branch.
This further leaves to unavoidable conflicts in composer.lock, so feature/branch ownes is forced to run `composer update`
and when it happens - you don't know how long it has bees since last update (you can check it in composer.json - sure)
, and if it's very long time - any dependencies issues fall on you, which can firther delay this feature/branch.
I'm waiting on your feedback.
@marcinrogacki
Copy link

agree

@michal-niedzwiedzki
Copy link

👍

@MariuszTasak
Copy link

👍

@pawlik
Copy link
Author

pawlik commented Dec 8, 2015

added to checklist

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment