Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v0.2 Release Checklist #70

Closed
7 tasks done
rickmanelius opened this issue Jan 2, 2018 · 8 comments
Closed
7 tasks done

v0.2 Release Checklist #70

rickmanelius opened this issue Jan 2, 2018 · 8 comments

Comments

@rickmanelius
Copy link
Contributor

rickmanelius commented Jan 2, 2018

Remaining actions:

  • Review release (product owner)
  • Approve release (product owner and release manager)
  • Create binaries (any DRUD maintainer)
  • Draft release notes (release manager)
  • Draft additional announcements for blog, newsletter, etc (not applicable at the moment)
  • Create release (release manager)
  • Update any package managers to point to new release (release manager)

For additional background information, please see our Product Release instructions here.

@rickmanelius
Copy link
Contributor Author

rickmanelius commented Jan 4, 2018

ddev-ui v0.2 Review

Executive Summary

Based on the following analysis, ddev-ui v0.2 is NOT YET ready for release.

Milestone Overview (Basic App Management)

The intention of this milestone is to provide more control over the typical tasks when adding, modifying, or removing applications from ddev. Areas of focus here are as follows:

  • Add an app from a local repo.
  • Remove app
  • Remove app and data
  • Access ddev describe information
  • Open site in new browser window

Testing

Performed by Rick Manelius as of 2018-01-29

Hardware

I’m using a laptop with the following high level specifications:

  • MacBook Pro: Retina 15-inch Mid 2015
  • 2.2 Ghz Intel Core i7
  • 16 GB 1600 MHz DDR3 RAM
  • 250 GB Hard Drive
  • macOS Sierra 10.13.2

Software Setup

  • Xcode
  • Go 1.9
  • Docker 17.12.0-ce
  • Git 2.14.3 (Apple Git-98)

Repositories Used

Preparation

  • Run make clean && make darwin and confirmed I can launch from DMG on mac.
  • Run npm install && npm start
  • Installed WordPress 4.9.2 and Drupal 7.56 sites operational with an active database.

Results

Testing

Testing

  • Add App from Repo drud/ddev-ui/issues/16
    • Repo without an existing ddev configuration.
      • Downloaded WordPress 4.9.2, unzipped, and created a parent folder "wordpress" to test project vs docroot.
      • Clicked "Add/Create Project"
      • Specified the Project Path
      • Project Name was auto populated
      • Renamed the Project Name
      • Moved the Docroot to one folder in.
      • Configuration was created and the site was spun up after asking for credentials to modify /etc/hosts.
    • Repo with an existing ddev configuration.
      • Downloaded WordPress 4.9.2, unzipped, and created a parent folder "wordpress" to test project vs docroot.
      • Clicked "Add/Create Project"
      • Specified the Project Path
      • Project Name was auto populated
      • Renamed the Project Name
      • Moved the Docroot to one folder in.
      • I was alerted that I would be overwriting the configuration given the detection of an existing configuration.
    • CONFIRMED
  • Delete Data drud/ddev-ui/issues/19
    • Both WP and Drupal sites were up and operational with a database.
    • Remove project via ddev rm leaves the database the next time they are spun up.
    • Remove project via ddev rm --remove-data removes the database as expected.
    • CONFIRMED

Needs Work

  • Describe App drud/ddev-ui/issues/18
    • Information is properly displayed.
    • Regression
      • The links to Mailhog and phpmyadmin no longer fire.
    • NEEDS WORK

Decisions

Based on the analysis above, ddev-ui v0.2 is NOT YET ready for release.

Recommendations

  • Instructions. The updated README.md command on local dev (npm install && npm start) wasn't fully accurate because it presumes a make clean prior. The first time I ran it I didn't see any sites up, but then it picked up after I ran make clean && make darwin. There are other gotchas that can occur (ensuring package.json isn't in a modified state, etc).
  • I noted that the "start from fresh CMS" is downloading an alpha version of Drupal 8 (8.5.0-alpha1). We should stick to stable releases, so only ones with an X.Y.Z format. This should be spun off into a new issue.
  • Config re-writes. In the CLI, we suggest users remove containers and simply run ddev start the next time they want to start the project back up. On ddev-ui, we're attempting to mirror that process. However, there is one important difference in that ddev-ui detects and re-writes the config.yml file each time rather than simply accepting the one that is already present. This can have negative end-user consequences, particularly if a user has specified overrides or additional hooks. To that end, we will need to find a way to do this in a non-descructive fashion moving forward. This should be spun off into a new issue.

Not Within DDEV-UI's Scope

  • Project Name Uniqueness: I found a regression on enforcing project name uniqueness in ddev cli. See comments

@rickmanelius
Copy link
Contributor Author

Updated the previous comment (#70 (comment)) to reflect what's left. Basically this is NOT yet ready for a release because of one regression and also waiting on final approval from @rfay on the #16 PR #75. Once both of those are done, I'll update my review to an approve and we can proceed with cutting this release.

@rickmanelius
Copy link
Contributor Author

Updated my review above. Basically, there are two follow-up issues to file and one release blocker (the links in the describe modal need to be functional links). Once that is fixed, I'm ready to approve the release.

@andrew-c-tran
Copy link
Contributor

andrew-c-tran commented Jan 30, 2018

@rickmanelius per your review, the following issues were opened:
#85 - start from fresh cms using non-stable versions
#86 - start from existing files always overwriting config.yml

the details link regression was accepted and merged in #84

as for the readme local dev instructions update recommendation, we're going to be changing a LOT of how the app spins up in dev mode with the implementation of 0.3 and the changes in workflow that comes with it, i think a complete readme rewrite will need to happen at that time. I've opened #87 as part of the 0.3 milestone to address this

@rickmanelius
Copy link
Contributor Author

ddev-ui v0.2 Review

Executive Summary

Based on the following analysis, ddev-ui v0.2 is ready for release.

Milestone Overview (Basic App Management)

The intention of this milestone is to provide more control over the typical tasks when adding, modifying, or removing applications from ddev. Areas of focus here are as follows:

  • Add an app from a local repo.
  • Remove app
  • Remove app and data
  • Access ddev describe information
  • Open site in new browser window

Testing

Performed by Rick Manelius as of 2018-01-29

Hardware

I’m using a laptop with the following high level specifications:

  • MacBook Pro: Retina 15-inch Mid 2015
  • 2.2 Ghz Intel Core i7
  • 16 GB 1600 MHz DDR3 RAM
  • 250 GB Hard Drive
  • macOS Sierra 10.13.2

Software Setup

  • Xcode
  • Go 1.9
  • Docker 17.12.0-ce
  • Git 2.14.3 (Apple Git-98)

Repositories Used

Preparation

  • Run make clean && make darwin and confirmed I can launch from DMG on mac.
  • Run npm install && npm start
  • Installed WordPress 4.9.2 and Drupal 7.56 sites operational with an active database.

Results

Testing

Testing

  • Add App from Repo drud/ddev-ui/issues/16
    • Repo without an existing ddev configuration.
      • Downloaded WordPress 4.9.2, unzipped, and created a parent folder "wordpress" to test project vs docroot.
      • Clicked "Add/Create Project"
      • Specified the Project Path
      • Project Name was auto populated
      • Renamed the Project Name
      • Moved the Docroot to one folder in.
      • Configuration was created and the site was spun up after asking for credentials to modify /etc/hosts.
    • Repo with an existing ddev configuration.
      • Downloaded WordPress 4.9.2, unzipped, and created a parent folder "wordpress" to test project vs docroot.
      • Clicked "Add/Create Project"
      • Specified the Project Path
      • Project Name was auto populated
      • Renamed the Project Name
      • Moved the Docroot to one folder in.
      • I was alerted that I would be overwriting the configuration given the detection of an existing configuration.
    • CONFIRMED
  • Delete Data drud/ddev-ui/issues/19
    • Both WP and Drupal sites were up and operational with a database.
    • Remove project via ddev rm leaves the database the next time they are spun up.
    • Remove project via ddev rm --remove-data removes the database as expected.
    • CONFIRMED
  • Describe App drud/ddev-ui/issues/18
    • Information is properly displayed.
    • Links to Mailhog and PHPmyadmin work
    • CONFIRMED

Decisions

Based on the analysis above, ddev-ui v0.2 is ready for release.

Recommendations

  • Instructions. The updated README.md command on local dev (npm install && npm start) wasn't fully accurate because it presumes a make clean prior. The first time I ran it I didn't see any sites up, but then it picked up after I ran make clean && make darwin. There are other gotchas that can occur (ensuring package.json isn't in a modified state, etc). This will be updated in v0.3 because there will be changes in the foundational elements of ddev-ui.
  • I noted that the "start from fresh CMS" is downloading an alpha version of Drupal 8 (8.5.0-alpha1). We should stick to stable releases, so only ones with an X.Y.Z format. This was already spun off into a new issue: add from cms distro is installing non-stable (alpha/beta) releases.
  • Config re-writes. In the CLI, we suggest users remove containers and simply run ddev start the next time they want to start the project back up. On ddev-ui, we're attempting to mirror that process. However, there is one important difference in that ddev-ui detects and re-writes the config.yml file each time rather than simply accepting the one that is already present. This can have negative end-user consequences, particularly if a user has specified overrides or additional hooks. To that end, we will need to find a way to do this in a non-descructive fashion moving forward. This was already spun off into a new issue: use existing config.yml if found instead of always overwriting

Not Within DDEV-UI's Scope

  • Project Name Uniqueness: I found a regression on enforcing project name uniqueness in ddev cli. See comments

@rickmanelius
Copy link
Contributor Author

Moving #71 to v0.2.1 as a smaller release so we can at least close out v0.2.0 functionality locked in prior to v0.3.0 related items. Handing over the assignment to getting any remaining packaging in place. Thanks for all the hard work and diligence!

@rickmanelius
Copy link
Contributor Author

Bumping to @andrew-c-tran as a housekeeping item to close this out.

@andrew-c-tran
Copy link
Contributor

andrew-c-tran commented Feb 5, 2018

Released - closing issue

  • Create binaries (any DRUD maintainer)
  • Draft release notes (release manager)
  • Draft additional announcements for blog, newsletter, etc (not applicable at the moment)
  • Create release (release manager)
  • Update any package managers to point to new release (release manager) (does not apply to DDEV-UI at the moment)

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

No branches or pull requests

3 participants