5.x - Update version-numbering pattern
Tasks
-
civicrm.org- Update extension validation to accept 4.7 as synonym for 5.x -
civicrm.org- Update extension validation to allow forward compatibility within 5.x series -
Upgrader and
set-version- Allow one to easily increment middle digit -
doc - Update RM docs
-
5.x-rc.md -
5.x-final.md -
5.x-patch.md
-
-
test.civicrm.org- Assess/update CI:-
civi-test-run -
civibuild upgrade-test - https://test.civicrm.org/job/CiviCRM-Core-Matrix/
- https://test.civicrm.org/job/CiviCRM-Ext-Matrix/
- https://test.civicrm.org/job/CiviCRM-WebTest-Matrix/
- https://test.civicrm.org/job/CiviCRM-Core-PR/
- https://test.civicrm.org/job/CiviCRM-Backdrop-PR/
- https://test.civicrm.org/job/CiviCRM-Drupal-PR/
- https://test.civicrm.org/job/CiviCRM-Packages-PR/
- https://test.civicrm.org/job/CiviCRM-Publish/
- https://test.civicrm.org/job/CiviCRM-Publish-Watch-Core/
-
- http://download.civicrm.org/latest - Display multiple autobuilds/pre-releases simultaneously
-
civicrm-core- Trial run, using installer/upgrader/distmaker/test-suite on v5.0 -
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: Thecivicrm.phpfile 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 filejs/crm.angular.jshas a function with a "remove me" notice -
docs-publisher- documentation/docs-publisher!87 (merged) -
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}.0is (initially) the same as the previousv4.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, feel free to open a pull-request in 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.