Release issueshttps://lab.civicrm.org/dev/release/-/issues2018-08-17T00:17:24Zhttps://lab.civicrm.org/dev/release/-/issues/15.x - Update version-numbering pattern2018-08-17T00:17:24Zcolemanw5.x - Update version-numbering pattern## 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 on...## 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.
https://lab.civicrm.org/dev/release/-/issues/3CiviCRM 4.7.31 installs don't report that a new release is available2018-06-05T21:48:37ZJonGoldCiviCRM 4.7.31 installs don't report that a new release is availableThis seems like it's at the intersection of the `latest.civicrm.org` microservice and the upgrade check code.This seems like it's at the intersection of the `latest.civicrm.org` microservice and the upgrade check code.https://lab.civicrm.org/dev/release/-/issues/4CiviCRM 5.0 tarballs include xml folder2018-04-09T22:59:37ZJonGoldCiviCRM 5.0 tarballs include xml folderThe Civi 5.0 Drupal tarball and WP zip file include the xml folder. I'm pretty sure this isn't intentional.The Civi 5.0 Drupal tarball and WP zip file include the xml folder. I'm pretty sure this isn't intentional.https://lab.civicrm.org/dev/release/-/issues/5Deprecate use of MD5Sums - Switch to SHA hashes or another mechanism to verif...2018-11-21T03:40:11ZhomotechsualDeprecate use of MD5Sums - Switch to SHA hashes or another mechanism to verify download integrity & publish on CiviCRM.orgCurrently each Civi release on Source Forge is accompanied by an MD5SUMS file to verify the integrity of the download.
[CiviCRM 5.1.2 on SourceForge](https://sourceforge.net/projects/civicrm/files/civicrm-stable/5.1.2/)
Due to the ease...Currently each Civi release on Source Forge is accompanied by an MD5SUMS file to verify the integrity of the download.
[CiviCRM 5.1.2 on SourceForge](https://sourceforge.net/projects/civicrm/files/civicrm-stable/5.1.2/)
Due to the ease of conducting MD5 [collision attacks](https://en.wikipedia.org/wiki/Collision_attack) and the fact that MD5 hashing is considered insecure for file download verification - CiviCRM should consider a switch to GPG or SHA Checksum verification options - and have these published on CiviCRM.org rather than residing solely on SourceForge.https://lab.civicrm.org/dev/release/-/issues/6Produce CiviCRM-Drupal8 tarballs2020-09-30T12:15:58ZbgmProduce CiviCRM-Drupal8 tarballsWhat needs to be done so that we can publish official CiviCRM-Drupal8 tarballs?
> "So I still think that it will be at least a two stage process....one is the drupal module...you could have that downloadable from civicrm.org, but to be ...What needs to be done so that we can publish official CiviCRM-Drupal8 tarballs?
> "So I still think that it will be at least a two stage process....one is the drupal module...you could have that downloadable from civicrm.org, but to be compliant with Drupal standards, it would also be nice for the civicrm project page to have the d8 drupal module" -- @jackrabbithanna
> "What we're missing infrastructure wise, is the build process to a composer package that puts civicrm-core and civicrm-packages together as per that gist" -- @jackrabbithanna
> "A one-step drupal 8 composer install for D8 seems to be where we should end up." @MikeyMJCO
> "yep their could be a composer.json int he drupal module that requires the combined civicrm-core + civicrm-packages .. OR people could download the module and run the composer require independently, and place it in the right place" [...] "that all will get itself sorted pretty quick once the gist steps are available from one composer require" -- @jackrabbithannahttps://lab.civicrm.org/dev/release/-/issues/7Publish the zetamailcomponents-mail fork on Packagist?2019-04-04T12:29:07ZbgmPublish the zetamailcomponents-mail fork on Packagist?Follow-up to https://lab.civicrm.org/dev/drupal/issues/36: since we cannot un-fork, can we publish our fork on Packagist?
This would help simplify the composer workflow, assuming we could then run `composer require civicrm/zetacomponent...Follow-up to https://lab.civicrm.org/dev/drupal/issues/36: since we cannot un-fork, can we publish our fork on Packagist?
This would help simplify the composer workflow, assuming we could then run `composer require civicrm/zetacomponents-mail` instead of having to edit the `composer.json` file manually.tottentottenhttps://lab.civicrm.org/dev/release/-/issues/8D8 composer installation method for ESR versions2021-09-21T21:01:40ZjackrabbithannaD8 composer installation method for ESR versionsSince only those folks that chip in and pay into the ESR problem have access to the CiviCRM ESR tarballs, there should be a composer based method that will always provide "the latest ESR release" ..
IDK how this can be done. Will CiviCR...Since only those folks that chip in and pay into the ESR problem have access to the CiviCRM ESR tarballs, there should be a composer based method that will always provide "the latest ESR release" ..
IDK how this can be done. Will CiviCRM need a private packagist account that people that pay into the ESR can use to composer require the ESR version?
If CT ends up not providing a ESR composer method ... Skvare may provide a how-to for how to :
1) install the latest ESR version, and a process for updating the ESR version ...
Target for this should be ESR 5.13, which I believe will be the next ESR?https://lab.civicrm.org/dev/release/-/issues/9Automatically tag the drupal-8 repository2019-11-22T21:42:52ZbgmAutomatically tag the drupal-8 repositoryWhen new CiviCRM releases are published, the main core+cms repositories are tagged for that version. Except Drupal8.
This can complicate the version tracking when one wants to track the core version (tag) + CMS version (currently only b...When new CiviCRM releases are published, the main core+cms repositories are tagged for that version. Except Drupal8.
This can complicate the version tracking when one wants to track the core version (tag) + CMS version (currently only branches are available).
Ex: https://github.com/civicrm/civicrm-drupal-8/pull/23https://lab.civicrm.org/dev/release/-/issues/11Security Releases - Update pre-release communications workflow2022-11-03T21:49:24ZtottenSecurity Releases - Update pre-release communications workflow__Synopsis__: This issue aims to organize discussion about security-releases and the practice of giving a *pre-release announcement* or *heads-up*. The aim is to produce greater clarity/consistency in the final policy without producing a...__Synopsis__: This issue aims to organize discussion about security-releases and the practice of giving a *pre-release announcement* or *heads-up*. The aim is to produce greater clarity/consistency in the final policy without producing a significant on-going admin work.
__Considerations__:
* Security releases have greater urgency than typical releases.
* Consumers of these releases often have distinct/independent deployment processes (the costs of which vary widely). Consequently, the heads-up can be quite useful in arranging capacity in advance.
* The heads-up can also be used ill - helping blackhats arrange capacity to exploit vulnerabilities before they're widely fixed.
* Mandating a fixed time-frame for a headsup would likely increase the turn-around time on security issues, and the current regimen already encourages poor turn-around time.
* The broader industry has examples where (a) security releases have adhoc scheduling, (b) security releases have specific/advanced notices, and (c) security releases have a "window" policy but no specific notices.
__Approaches__:
* __(:one:) Status quo__:
* __What__: Formally, the [current policy](https://civicrm.org/security) treats the first+third Wednesday as windows in which we *may* do security releases, and there is no *formal* policy of giving heads-up. However, there are informal practices of (a) sending heads-up to `civicrm-dev@` and random MM channels (b) preferring third Wed over first Wed.
* __Pro__: The informality and obscurity of the announcements feels like it mitigates the concern about blackhats using this information systematically. (That may or may not be true.)
* __Con__: It fosters an *expectation* of announcement, even if there is no *guarantee* of announcement.
* __(:two:) Kill the informal headsup__:
* __What__: Retain the current window policy, but stop the informal practice of sending heads-up.
* __Pro__: Consistent behavior. Less admin overhead. No false expectations.
* __Con__: Harder for downstream to mobilize.
* __(:three:) Formalize with one medium for headsup__:
* __What__: Update the public policy to say that we give a headsup. Specify one medium for announcements - it will *only* and *always* go to the "Security Notifications" mailing list.
* __Pro__: More reliable and more fair
* __Con__: Easier for blackhats to mobilize.
* __Issue__: Should sort out the edge-case where "we have a security patch that's ready to go, but that only came a couple days before the window, so we have to choose to choose lesser evil of... waiting an extra 2-3 weeks for another window or giving short/limited/no notice.
__Meta__
* If additional proposals are made, please give them an identifying code; and, if possible, include a summary in the description of this issue.
* Related: [Security Releases - Update post-release communications workflow](https://lab.civicrm.org/dev/release/issues/10)https://lab.civicrm.org/dev/release/-/issues/15Remove/Stop offering D6 releases on https://civicrm.org/download2020-05-06T15:05:55ZhomotechsualRemove/Stop offering D6 releases on https://civicrm.org/downloadWe're still publishing, whether through an error or through an oversight, Drupal 6 releases despite no longer supporting D6 and publishing a D6 tarball that doesn't work on D6 (No PHP 3.x support in CiviCRM).
Can we remove this source ...We're still publishing, whether through an error or through an oversight, Drupal 6 releases despite no longer supporting D6 and publishing a D6 tarball that doesn't work on D6 (No PHP 3.x support in CiviCRM).
Can we remove this source of confusion.
Discussion: https://chat.civicrm.org/civicrm/pl/quje115ipbfhbe5pjkzn84zsurbgmbgmhttps://lab.civicrm.org/dev/release/-/issues/16We should not be auto-generating 5.xx.beta1.mysql.tpl files2021-04-09T01:51:15ZcolemanwWe should not be auto-generating 5.xx.beta1.mysql.tpl filesI'm pretty sure these `beta1` files are getting auto-generated by the releaser. They have their ~~pros and~~ cons.
**Cons**
- Generating them before they're actually needed causes people testing the RC to miss out on the upgrade steps (...I'm pretty sure these `beta1` files are getting auto-generated by the releaser. They have their ~~pros and~~ cons.
**Cons**
- Generating them before they're actually needed causes people testing the RC to miss out on the upgrade steps (the empty step is created, the site upgrades to RC, it registers `xx.beta1` as having been run, then someone adds some actual content to the step, the site upgrades to a later version of the same RC, but the upgrade code thinks it's already run).
- Extra noise during the upgrade process with empty steps doing nothing
**Pros**
- Can't think of any.5.37.0https://lab.civicrm.org/dev/release/-/issues/17The version numbers for core-extensions should match core-proper.2021-05-17T19:27:11ZtottenThe version numbers for core-extensions should match core-proper.https://lab.civicrm.org/dev/release/-/issues/19ESR Workflow: Post full suite of resources at start of cycle2023-01-13T18:46:04ZtottenESR Workflow: Post full suite of resources at start of cycleBackground / Motivation
-----------------------
Every 6 months, we designate a version for extended security support. When there's a new security release, the ESR version is posted to Gitlab (`esr/core`, `esr/packages`, `esr/drupal-8`, ...Background / Motivation
-----------------------
Every 6 months, we designate a version for extended security support. When there's a new security release, the ESR version is posted to Gitlab (`esr/core`, `esr/packages`, `esr/drupal-8`, and so on -- collectively, the `esr/*` projects).
If you are sysadmin who wants to be _prepared_ for future security updates, then you would look to `esr/*` and do a trial-run. Make sure you have access/credentials. Make sure you can find the spot for the releases. Make sure you're targeting the right version. Make sure your tools (like `composer`) are configured to pull from there.
However, if there hasn't been a security release, then there may not be anything published on `esr/*`. This interim period invites some confusion. On one hand, there's no security-release to publish -- so the regular security-release scripts don't apply. On the other hand, if you want to be ready, then you need something to look at. The result is that we improvise during the interim.
Goal
----
Whenever we start new ESR cycle, immediately publish to `esr/*`. Include sufficient resources that enable the sysadmins to do a "dress rehearsal" (downloading/install using the exact same procedure as for a security fix). For example, suppose we're discussing v5.51 which started its extended support circa Aug 3. Here are some materials that you might expect to find (circa Aug 3):
* In the main repo, the tarballs for the `5.51.x` releases
* In each repo, the branch (`5.51-esr`).
* In each repo, the tags for specific patch releases (`5.51.x` or `5.51.x+esr`).
* In each repo, package-registry entries for each release (`5.51.x` or `5.51.x+esr`).
* In the main repo, links for the documentation interim changes (release announcements/notes for 5.51, 5.50, 5.49, 5.48, 5.47, 5.46)
Questions
----------
Are there other resources that you expect in this period?
If 5.51 starts public-support in July and starts extended-support in August... then... when should 5.51 become available in `esr/*`? Start of July? Start of August?
(If 5.51 is published to `esr/*` in July, then it will overlap with the tail-end of 5.45. Would it be confusing to see both during July?)https://lab.civicrm.org/dev/release/-/issues/21year typo2023-12-09T05:01:31Zjofranzfranz@systopia.deyear typo`Jan 3, 2023` in https://lab.civicrm.org/dev/release/-/blob/master/README.md`Jan 3, 2023` in https://lab.civicrm.org/dev/release/-/blob/master/README.mdeileeneileenhttps://lab.civicrm.org/dev/release/-/issues/245.69.1 critical error: Undefined array key "crmSearchTasks" in "ext/search_ki...2024-02-01T22:42:39ZDmitry Smirnov5.69.1 critical error: Undefined array key "crmSearchTasks" in "ext/search_kit/search_kit.php" on line 61```
PHP Warning: Undefined array key "crmSearchTasks" in ext/search_kit/search_kit.php on line 61
PHP Warning: Trying to access array offset on value of type null in ext/search_kit/search_kit.php on line 61
PHP Fatal error: Uncaught T...```
PHP Warning: Undefined array key "crmSearchTasks" in ext/search_kit/search_kit.php on line 61
PHP Warning: Trying to access array offset on value of type null in ext/search_kit/search_kit.php on line 61
PHP Fatal error: Uncaught TypeError: in_array(): Argument #2 ($haystack) must be of type array, null given in ext/search_kit/search_kit.php:61
```