Not at all. See eg this issue ; it is unfortunate that it was closed without a solution.
Also, you may be interested in
opened 03:56PM - 22 Oct 18 UTC
closed 09:33PM - 21 May 19 UTC
Before we can move from METADATA being the source of truth for registered packag… es to JuliaRegistries/General being the source of truth, we need a process and infrastructure for registering packages. Here's an outline of some of my thoughts on what the process should look like.
### 1. Request
**Who: package maintainer**
Package maintainer proposes a new version tag
- perhaps via an API endpoint?
Possible data to include:
- uuid
- repo url
- branch
- tree hash
- commit hash
- version number
Or maybe just one of `patch`, `minor` or `major` and version number is automatic based on existing version numbers. This is almost certainly too much data but I wanted to mention all the possible info one might want. Ideally we'd like to automate as much of this as possible from the repo.
### 2. Check
**Who: automated**
Automated validation of whether a proposed version tag is acceptable.
Check that:
- version number is sensible (next patch, minor or major)
- install the package version by itself
- run the tests for the installed package
- test variations on dependencies
- check if compat claims are plausible
- reverse dependency testing
- check semver compliance?
Produces report of results
### 3. Review
**Who:**
- **package maintainer** (always)
- **registry manager** (sometimes)
Maintainer review:
- accept or reject based on report
If maintainer accepts, go to registry manager review:
- if meets auto-approval criteria, it is fully approved without manual review
- otherwise proposer can request manual review from a registry manager
- abilities needed:
- maintainer to give reasoning
- manager to give feedback
- manager to make a decision
- probably good to take place on a PR somewhere
### 4. Tagging
**Who:**
- ideally **automated** via GitHub API
- otherwise manually done by **package maintainer**
Propagate git tag to package repo
- should used signed tags signed by some authorized entity
Can we use the github API to create tags automatically?
- https://developer.github.com/v3/git/tags/#create-a-tag-object
- perhaps an app that only requires that permission
What would the workflow be for non-github packages?
- even if it’s very manual, we should have one
- have a git repo endpoint that we create tags at
- then document how to pull tags from it?
The tagged tree also needs to be publicly accessible but I think tagging guarantees that in git. If the tag does not match the version approved in the review step above then the version is not properly tagged and the rest of the process is blocked until the tag is fixed.
### 5. Registration
**Who: automated**
Once a new version has been approved and tagged, it can finally be registered. This consists of making the appropriate updates to the registry repo. This will be completely automatic.
My impression is that the current setup is considered a collection of temporary measures, so no one feels like documenting it. The best source is this discussion , but it hard to find for newbies. I asked my questions because I noticed some PRs in the related code checking the Project.toml, and I was curious.
1 Like