Updated: The file manifest carries the checksums of the deploy without a needless PHP-FPM reload

Updated: A deploy reloads PHP-FPM only when OPcache cannot pick up the change, and warms the caches afterwards

A graceful PHP-FPM reload is not confined to one site. The master asks every
child of every pool to finish its request and starts no new child until the
last one has, for up to process_control_timeout (300 s on Plesk). Each request
that arrives in between waits for the longest request running on any site of
that PHP version. Measured on alpha: with one 25 s event stream open, the next
page waited 22.4 s after a reload; without one, 3.9 s; a 135 s request on
another pool turned the waiting requests into 504s. This is what made the
first admin request after a deploy take 50 to 100 s.

Updated: [DeploySettings] PhpFpmReload=auto (default) skips the reload when the
pool's OPcache revalidates files (validate_timestamps on, revalidate_freq at
most 60 s, read from php-fpm -i and the pool file) and waits revalidate_freq
plus one second instead, so the rendered-output caches are still cleared only
after PHP-FPM runs the new code. always and never are the other values;
deploy --fpm-reload forces a reload (php.ini or pool changed, new extension,
files removed or renamed in place).
Added: [DeploySettings] WarmUpURL[]: the last step requests each URL once, one
after the other, from a detached background process, so the first visitor
does not rebuild the compiled templates and the INI, override, translation,
design and packed-file caches, and several first visitors do not rebuild
them at once. The deploy does not wait for it.

Updated: The file manifest carries the checksum of the JSON package format page

Updated: The JSON package format page shows rich text without the editor's namespace URIs

Updated: The file manifest carries the checksums of the JSON package format

Added: A JSON format for packages, an alternative serialization of the classic package model

A package can be written as package.json and JSON documents instead of
package.xml and XML documents. Every XML document of the package (the
definition, the files of its items, the object files) is mirrored element
for element in JsonML, rich text kept as its XML string, so the package
handlers and datatypes read the same DOM from either format and a package
converts from XML to JSON and back without loss. The classic format stays
the default; a classic package, its archive and its installation are
unchanged. Verified on every installer package of the 7x repository and a
test subtree: every document canonically equal after XML -> JSON -> XML,
every other file byte for byte, the JSON a fixed point.

- expPackageJson: the mapping, conversion of package directories and
  archives, validation, checksums (SHA-256 of every file in package.json)
- share/package/schema/package-v1.json, the JSON Schema of the format, and
  expJsonSchemaValidator to check documents against it
- eZPackage: export in either format (format json|xml), import and fetch
  detect the format by content, documents are read from XML or JSON,
  package metadata (<metadata><entry key>) for tools, archiveDirectory()
- Install as drafts, a generic install option: content objects become
  drafts, nothing is published, no published object changes; existing
  objects get a new draft or are left alone, an object of another class is
  a conflict; other items are listed instead of installed
- expPackageConflictReport: what an install meets here, by remote id
- ezpm: export --format=json, convert, validate, check, install --as-drafts
- Setup > Packages: Download as JSON, the package's format and metadata,
  the install page's report by remote id and the option to install as drafts
- The upload check and the package catalog accept package.json
- package.ini [PackageFormatSettings]; documentation in
  doc/bc/6.0/package-json-format.md; tests in expPackageJsonTest

Updated: The file manifest carries the checksums of the service declarations that opt in to the assistant