Since writing cdbrelease, CDB has added a new set
of stable APIs suitable for creating releases. Major
changes planned:
- Use the JSON API and token auth for everything
instead of scraping site HTML.
- Switch to using CDB's standard mechanisms for
some config, such as *.conf for versions and
.cdb.json for static settings.
- Switch to zip uploads so we can locally control
exports, since CDB uses git-export-all which does
not properly support .gitattributes export-subst.
This also involves a significant rework of the
configuration interfaces to support the new
.cdb.json source, and mirroring the git repo is now
mandatory, as using zip upload, we cannot rely on
CDB to access the repo itself directly.
New configuration interfaces are ostensibly done,
CDB components need to be reworked still.
- Automatically load detail edits from meta JSON, allowing release
of new descriptions to sync with release of package versions.
- Load long description from external markdown file.
- Automatically calculate provides/depends info if needed.
If --fromgit=<url> is specified:
- Shallow-clone the repo.
- Export the tree from the clone.
- Run .cdbrelease.lua hook in the root of the tree.
- Merge any data returned into config.
.cdbrelease.lua can do more-or-less whatever lua allows (e.g.
using dofile, filesystem access, etc.) to figure out the settings
it wants to provide. This allows it to do things like include
files from mods for shared versioning logic and perform more
complex version number calculations, like NodeCore does. It could
also be a security risk, so this should be used only on repos that
the user has good control over.
The canonical example is for .cdbrelease.lua to compute its own
version number from stats that get baked into the file by the
export step based on .gitattributes. Things like defaulting the
pacakge name and author are possible too.
Settings that are already explicitly specified at an earlier step
are ignored from .cdbrelease.lua.
