mirror of
https://github.com/NLnetLabs/krill.git
synced 2026-09-10 03:27:40 +02:00
Ximon EighteenandGitHub
faf6bd2549
Support multiple signers of different types behind a HSM feature flag, and support in principle selecting which signer to use for which purpose. (#539)
76 lines
3.1 KiB
Markdown
76 lines
3.1 KiB
Markdown
Krill Developer Documentation
|
|
=============================
|
|
|
|
> NOTE: If you are looking for Krill user or operational documentation, please have
|
|
> a look [here](https://rpki.readthedocs.io/en/latest/krill/index.html).
|
|
|
|
This documentation is aimed at providing Developers at NLnet Labs insight into how the
|
|
core Krill code works. But there are no secrets here, so anyone with a healthy interest
|
|
in the guts of this Krill species is welcome to have a look.
|
|
|
|
This is still a work-in-progress. The plan is to have separate chapters which explain
|
|
components and/or concepts in Krill:
|
|
|
|
1. [Krill Daemon Code](./01_daemon.md)
|
|
2. [Krill CLI Code](./02_cli.md)
|
|
3. [Event Sourcing General Overview](./03_es_concepts.md)
|
|
4. [Event Sourcing in Krill](./04_es_krill.md)
|
|
5. [Repository Manager](./05_repo_manager.md)
|
|
6. [Certificate Authority Manager](./06_ca_manager.md)
|
|
7. [Multi-User Feature](./multi_user/readme.md)
|
|
8. [HSM Feature](./hsm/readme.md)
|
|
|
|
Release Versions
|
|
----------------
|
|
|
|
Krill uses semantic versioning. We are currently still below version 1.0.0, meaning
|
|
that we may have incompatible API changes in MINOR releases. E.g. from 0.8.2 to 0.9.0.
|
|
We use PATCH versions for minor functionality as well as bug fixes.
|
|
|
|
Whenever it's feasible we will use release candidates, even for patch releases as they
|
|
may still include functional changes. We may skip this only in case a patch release is
|
|
purely an urgent bug fix release which does not introduce any functional changes.
|
|
|
|
In future, after 1.0.0, we plan to use semantic versioning rules as described here:
|
|
https://semver.org
|
|
|
|
I.e.:
|
|
Given a version number MAJOR.MINOR.PATCH, increment the:
|
|
1. MAJOR version when you make incompatible API changes,
|
|
2. MINOR version when you add functionality in a backwards compatible manner, and
|
|
3. PATCH version when you make backwards compatible bug fixes.
|
|
|
|
Release Checklist
|
|
-----------------
|
|
|
|
- [ ] Make a prep-release branch off the dev branch
|
|
- [ ] Update version in Cargo.toml
|
|
- [ ] Update Changelog.md
|
|
- [ ] Add the version to KeyStoreVersion
|
|
- [ ] Bump the version in the OpenAPI docs (to be deprecated in future)
|
|
- [ ] Update https://krill.readthedocs.io/en/latest/cli.html
|
|
- [ ] Make blog post (if deemed useful)
|
|
- [ ] Make a tagged release Lagosta and add it to Krill (refer to tag in commit)
|
|
- [ ] Make a PR to the dev branch, review, merge
|
|
- [ ] Make a PR to the main branch, final review, merge
|
|
- [ ] Make a GH release
|
|
- [ ] Add packages if needed (automated, may just work)
|
|
- [ ] Cargo publish
|
|
- [ ] Inform users: mailing list, discord, twitter
|
|
|
|
|
|
Release Candidate Steps
|
|
-----------------------
|
|
|
|
We aim to have RC releases available for 2-3 weeks during which time they can be tested
|
|
and hopefully accepted. If a new RC is needed, then we could use a shorter period for the
|
|
new RC release dependent on the nature of the fix.
|
|
|
|
Generally speaking we will want to do the following:
|
|
|
|
- [ ] Deploy to our own production environment
|
|
- [ ] Work with users with support contracts to test if needed
|
|
- [ ] Test data migrations of real systems (in addition to unit testing during development)
|
|
- [ ] Chase translations for new UI labels
|
|
- [ ] Get confirmation from a number of users
|