Common Repository Structure
Hyperledger projects are required to maintain a standard set of files in each repository. This document describes the required and recommended files.
Required Files with Specified Content
Repositories MUST have these files with the specific content in the linked files, or a file with a link to the specified content with minimal exposition. These files MUST be at the root of the repository.
(Unless an exception has been made by the Hyperledger Governing Board)
Required Files with Variable Content
Repositories MUST have these files. Named files MUST be at the root of the repository, and may have format suffixes such as
A description of the project and contain information or links to information such as
- A reference to the Apache license (required).
- The current and important past releases
- Documentation for developers and users
A list of all current maintainers with contact info. A separate document covers the specifics.
Directions on how to contribute code to the project, or a pointer to the Wiki page with that information.
A human readable list of recent changes. Changes should at least include the current release. This file may be maintainer curated or mechanically produced.
- Continuous Integration / Continuous Delivery (CICD) configurations
Configurations needed to run CICD on Hyperledger provided systems.
Repositories SHOULD have these files. Named files SHOULD be at the root of the repository
- As per section 4 subsection d of the Apache License, Version 2
- Apache License Header information in each source code file.
For new files added to Hyperledger repositories they SHOULD include the snippet
SPDX-License-Identifier: Apache-2.0as part of the header. (see the Copyright and Licencing Policy)
- Build files consistent with the implementation language, such as…
- For Ruby a
- For Java one of a Maven
pom.xml, an Apache Ant
build.xml, or a Gralde
- For Python
- For Go
- For Rust a
- For multi-lingual repositories a
- For other languages, other standard build files a practitioner of the language would expect.
- Testing code
Code to test the code in the repository (such as unit tests), in a location appropriate for the language.
Not all repositories can be tested (homebrew, docs), which is the only reason this is a SHOULD.
Repositories MUST NOT have these files
- Executable binaries and shared library files built by code in the repository
.dylibfiles not otherwise part of a third party library.
In order to help automate checks a repolinter file and supporting scripts can be found in Hyperledger Community Management Tools. Note that where the two repositories and tooling differ this document takes precedence.