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/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/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?)