search

thinkshout / bene

Bene Drupal 8 distribution
10 stars 1 forks source link

Support: Release Management #285

Open juliaford opened 5 years ago

juliaford commented 5 years ago

Overview

Once repos have been refactored and a build process has been set up, we need to think about how releases will happen going forward. I'd recommend hashing out the following:

  1. Release cadence - I think 24 hours after a security issue and quarterly seems OK.
  2. Testing and QA - document how client sites can tie to a pre-release tag or dev branch and test on a multidev with the new composer-or-build setup.
  3. Creating normal packaged releases on Drupal.org so tarballs function normally

Dev [? hrs]

This ticket is done when:

TBD.

mortenson commented 5 years ago

On thing I noticed: In Semantic Versioning, Major/Minor/Patch version numbers can not contain leading zeroes. Bene releases currently contain leading zeroes in their patch releases. I'm not sure what the technical implications of the current numbering system is.

mortenson commented 5 years ago

Note that we'll need to change our release naming on Github to accommodate for the https://www.drupal.org/node/2715441#comment-11669389 workaround - need to use the short form (X.X.X) instead of the real tag name (8.x-X.X.X).

mortenson commented 5 years ago

@unclegcb Here's the release I made which seems to work, but may not be ideal because it doesn't include patch versions: https://github.com/thinkshout/bene/releases/tag/2.07

Looks like Lightning uses major minor patch versions, like 2.0.0 (not sure how they'll handle Drupal 9, eek!). Thunder includes the Drupal major version, like 8.2.0. We should figure out how we want to do tagging before we start using this.

unclegcb commented 5 years ago

Love the Thunder versioning, let's do it.

Quick notes on conversation we just had about the potential for these sites to "divorce" from our circle/composer framework and return to a Bene Upstream:

  1. All new Pantheon sites should be initialized from the Bene Upstream, even though we will immediately deactivate it. This gives them some theoretical shared history.
  2. If a site wants to leave our circle process and switch back to the Pantheon Upstream, they have to have no custom composer requirements. (theoretically, a Drupal module with no non-Drupal requirements could be allowed, but that would be the limit)
  3. Divorce option 1, to return to the Upstream, would be a hard git history reset:
    • Put the upstream back into pantheon.yml
    • Apply upstream updates, observe massive conflicts
    • Copy the upstream files over top of the site, overwriting all conflicting files (but preserving the custom theme, etc)
    • Commit these 'merge' commits, push to Pantheon
    • Force push this version of the repo to Github as well (if the client wants to maintain github)
    • Theoretically, we are now at a point where future upstream updates can be directly applied through the pantheon dashboard