Remaining actions:
For additional background information, please see our Product Release instructions here.
Current diff https://github.com/drud/ddev/compare/v0.18.0...HEAD
Updated issue summary to reflect roadmap updates as part of release checklist.
Here is my working copy so far.
Based on the following analysis, ddev v0.19.0 is not ready for release.
TODO
Additionally, there are...
Performed by Rick Manelius as of 2018-05-29
I鈥檓 using a laptop with the following high-level specifications:
git checkout d4c4590fmake clean && make darwinddev version => v0.18.0-20-gd4c4590fBased on the following analysis, ddev v0.19.0 is not ready for release.
Found a few things in my initial issue scan that could be updated/improved.
I'm intending to test the following for the release. @rfay, if you have any additional items to callout and test more explicitly, let me know. I'm focusing on end-user changes and new features vs bug fixes, but if there are ones that I should draw more attention to...
There is a significant amount of work being done under the hood in this release in preparation of getting back onto a more formal roadmap schedule (see updates here https://github.com/drud/ddev/wiki/Roadmap). Still, there were several user experience features worth calling out.
In addition there were a considerable amount of bug fixes and optimizations (see https://github.com/drud/ddev/compare/v0.18.0...e5d9c86020). We've addressed regressions on Linux support, moved the docker image definitions into the repo, and performed upgrades to our testing infrastructure.
@rickmanelius I reviewed the list you put there and think it's good. I was quite surprised how many commits/PRs we have in this release. I think people would just choke on the info if we tried to describe every fixed bug.
@rickmanelius Please test against current master: https://github.com/drud/ddev/commit/4ddabc7c15620842e185476b6dfc15e944e58479, which hopefully will be the hash we tag as v0.19.0
@rfay Yup I checked out that exact commit, so I'm all set there.
BTW, I'm now done testing 3 of 5. I think I have found a regression for the multiple hostname validation. I'm posting it here in case this is how it was intended to work.
ddev configadditional_hostnames: [site1, site2]ddev startddev startddev rm, the other sites are now available again.But that never meant that we solved the possibility of having two projects fighting each other for additional_hostnames. I think this is mentioned in the additional hostname uniqueness issue.
Edit: See https://github.com/drud/ddev/pull/825 "This PR does not solve the problem of multiple projects competing for one hostname."
@rfay Excellent. Thanks for the insight on that. I'll move that to a recommendation then and test conflict just within a project.
Based on the following analysis, ddev v0.19.0 is ready for release.
There is a significant amount of work being done under the hood in this release in preparation of getting back onto a more formal roadmap schedule (see updates here https://github.com/drud/ddev/wiki/Roadmap). Still, there were several user experience features worth calling out.
In addition there were a considerable amount of bug fixes and optimizations (see https://github.com/drud/ddev/compare/v0.18.0...e5d9c86020). We've addressed regressions on Linux support, moved the docker image definitions into the repo, and performed upgrades to our testing infrastructure.
Performed by Rick Manelius as of 2018-05-30
I鈥檓 using a laptop with the following high-level specifications:
git checkout 4ddabc7cmake clean && make darwinddev version => v0.18.0-26-g4ddabc7cddev configddev start finished, I observe 3 URLs posted: http://PROJECTNAME.ddev.local, http://PROJECTNAME.ddev.local, and http://127.0.0.1:RANDOMPORTdocker ps -a and located the PROJECTNAME nginx container and confirmed the portnumber routes to the HTTP port.ddev list doesn't show the 3rd URL without the project name. That's fine.ddev describe -j shows the http://127.0.0.1:RANDOMPORT value in the "urls" key.ddev ssh and drush dl backup_migrate and drush en backup_migrateddev rm --remove-data then ddev startddev import-db --src=~/Downloads/drupal-7.59.ddev.local-2018-05-30T20-00-39.mysql.gzddev import-db with the corrected file and it imports!ddev config before overriding default HTTP/HTTPs ports to 81:444.ddev start and standard site install.ddev restart and ddev sshtouch test.php with 'ddev configadditional_hostnames: [site1, site2]ddev startddev startBased on the following analysis, ddev v0.19.0 is ready for release.
Ok... I'm happy with how this turned out. I'm still not happy that I'm not able/willing to give Windows 10 the attention it needs, but I may need to rely more on @andrewfrench in the future to confirm parity when @rfay gets a Windows specific fix in (and vice versa when @andrewfrench submits a PR).
Ready for getting this together as a release. Thanks, everyone!
Yay! @andrewfrench and I will schedule time today to go through the release process and document it in docs/developer.
@rickmanelius responses to your Recommendations:
HTTPS on 127.0.0.1: I still would like to see HTTPS on the direct localhost:RANDOMPORT webhead connection
If you'd like HTTPS on the web container port, it would mean duplicating the cert generation features in the web container or possibly changing the architecture to terminate HTTPS on the web container. It would also mean turning on a separate port for nginx, and exposing 2 different ports from the web container. It's not a small rock, and I'm not sure how it fits architecturally.
Backup Migrate gzip compression library. We should get this installed on the nginx container
I didn't understand this statement. I assume you might be referring to the backup_migrate bug in https://www.drupal.org/project/backup_migrate/issues/2926610, which we don't have any control of. Anyway, when you do a direct download of a backup_migrate db, it doesn't get gzipped.
Multiple Hostnames. While this is a nitpick, not everyone understands the multiple ways of inputting .yaml. The uncommented entry is "additional_hostnames: []" whereas the instructions use the syntax of newlines prefaced by a "-". It might be worth making those consistent
I agree with your concern on that. The reason that the default is the [] array syntax is that's what golang outputs for an empty yaml array. The bulleted yaml approach used in the docs/examples there is easier to read and easier to use. Both work. I don't know any reasonable way to get the golang yaml to output the bulleted version, so we could change the doc to use the array syntax if that's important.
we are not validating if other hostnames are actively being used, so it's possible to collide and put the router in an unhealthy status.
I think we should probably figure out how to solve this one in Make ddev-router more transparent about failures. I added a note about this case in that issue.
Removing this from the v.19 milestone as we close out that release using this checklist.
Release generated. Blog articles and newsletter shipped. Last step on @dclear to update the roadmap to reflect the completed milestone and we can close this out.
I edited the op with a checkbox for "Followup issues spun off if we need them."
Closed Milestone
https://github.com/drud/ddev/milestone/30?closed=1
Closed project board
https://github.com/orgs/drud/projects/12
Updated roadmap
https://github.com/drud/ddev/wiki/Roadmap
Closing, as I believe this is done.
Most helpful comment
Ok... I'm happy with how this turned out. I'm still not happy that I'm not able/willing to give Windows 10 the attention it needs, but I may need to rely more on @andrewfrench in the future to confirm parity when @rfay gets a Windows specific fix in (and vice versa when @andrewfrench submits a PR).
Ready for getting this together as a release. Thanks, everyone!