## Tasks * [x] `civicrm.org` - Update extension validation to accept 4.7 as synonym for 5.x * [x] `civicrm.org` - Update extension validation to allow forward compatibility within 5.x series * [x] *Upgrader* and `set-version` - Allow one to easily increment middle digit * [ ] [doc](https://lab.civicrm.org/development-team/Release-Management/tree/master/doc) - Update RM docs * [x] `5.x-rc.md` * [x] `5.x-final.md` * [x] `5.x-patch.md` * [x] `test.civicrm.org` - Assess/update CI: * [x] `civi-test-run` * [x] `civibuild upgrade-test` * [x] https://test.civicrm.org/job/CiviCRM-Core-Matrix/ * [x] https://test.civicrm.org/job/CiviCRM-Ext-Matrix/ * [x] https://test.civicrm.org/job/CiviCRM-WebTest-Matrix/ * [x] https://test.civicrm.org/job/CiviCRM-Core-PR/ * [x] https://test.civicrm.org/job/CiviCRM-Backdrop-PR/ * [x] https://test.civicrm.org/job/CiviCRM-Drupal-PR/ * [x] https://test.civicrm.org/job/CiviCRM-Packages-PR/ * [x] https://test.civicrm.org/job/CiviCRM-Publish/ * [x] https://test.civicrm.org/job/CiviCRM-Publish-Watch-Core/ * [x] http://download.civicrm.org/latest - Display multiple autobuilds/pre-releases simultaneously * [x] `civicrm-core` - Trial run, using installer/upgrader/distmaker/test-suite on v5.0 * [x] `civicrm-core` - Update various copyright headers from "4.7" to "5.x". * [ ] `civicrm-drupal` - SPECME: The *.info files are set to 4.7 and twiddled on release. For git-based deployments, should we do anything to maintain these? * [ ] `civicrm-wordpress` - SPECME: The `civicrm.php` file is set to 4.7 and twiddled on release. For git-based deployments, should we do anything to maintain these? * [ ] *Extension author outreach* - Grep universe for READMEs/docs. Send mail-blast with suggested updates. * [ ] `civicrm-core` - The file `js/crm.angular.js` has a function with a "remove me" notice * [x] `docs-publisher` - https://lab.civicrm.org/documentation/docs-publisher/merge_requests/87 * [x] `civicrm-sysadmin-guide` - https://github.com/civicrm/civicrm-sysadmin-guide/pull/75 ## FAQ __Q: Would it be better to say `v4.8.0` vs `v5.0.0` vs `v5.1803.0` vs `v18.3.0` vs `v33.0.0`?__ They're all basically the same. All of these options will give *someone* the heebeegeebees -- because we've been doing 4.7.x for two years, and anything that looks different will look different, and different is scary. The fundamental message should be this: * The change in number is superficial. * The substantive editorial/QA regime for `v5.{$Y}.0` is (initially) the same as the previous `v4.7.{$Z}`. * The new numbering makes it to easier to administer minor patch updates, enabling us to consider more fine-tuned maintenance regimes. There are bikesheddy reasons to favor one or another. __Q: But I think there should be substantive change!__ Grand! Please head over to #2 to weigh-in on proposals or add new ones! (Or, if you want to focus-in on the [main review criteria](https://docs.civicrm.org/dev/en/latest/standards/review/), feel free to open a pull-request in [civicrm-dev-docs](https://github.com/civicrm/civicrm-dev-docs).) __Q: Does this mean you're going to start making more, bigger, scarier changes more often?__ No. This is strictly a superficial realignment of the numbers. In fact, the general tenor of editorial policy has been toward tightening rather than loosening standards.