Newer
Older
ARF005 - OpenAPIs for World Storage Representation
# Workspaces
## ETSI Forge
Contains the source code and specification related to the World Storage API.
[Access to the Forge](https://forge.etsi.org/rep/arf)
[Access to the project: ARF005 – World Storage API](https://forge.etsi.org/rep/arf/arf005)
## ETSI Lab
Contains the source code and documentation related to the wrappers, the Unity plugin and the validation application. We will create an independent project for each item. A project called Management has already been created for administrative purpose.
[Access to the Lab](https://labs.etsi.org/rep/arf)
[Access to the subgroup World Storage API Helpers](https://labs.etsi.org/rep/arf/world-storage-api-helpers)
Contains temporary office documents that are edited collaboratively and all other stuff that don’t fit in the Forge or the Lab.
[Access with authentication](https://etsihq.sharepoint.com/:f:/s/Whitepapers/EoitUA6NUWtCkUe69C5x7Y4B-ctyOMXB6SX-jrR0oElYkw)
[Access without authentication](https://etsihq.sharepoint.com/:f:/s/Whitepapers/EoitUA6NUWtCkUe69C5x7Y4B15QjoFl-a_wpimo0hs-Jrw)
# Tools
## Swaggereditor
https://forge.etsi.org/index.php/tools/rest-apis
https://forge.etsi.org/swagger/editor/
## API generation
https://openapi-generator.tech/
Codegen
https://swagger.io/tools/swagger-codegen/
https://swagger.io/docs/open-source-tools/swagger-codegen/
# Branching Policy
Distributed version control systems like Git offers developers great flexibility to share and manage code. But a branching policy is crucial to collaborate more easily while keeping track of releases with bug fixes.
We consider 5 categories of branches:
- **develop**: collects the different features. While it is recommended that this branch be as stable as possible, each commit is not considered as a release, but much more as a pre-release.
- **feature**: dedicated to the development of features (named ***feature/*** *featureName*). These feature branches allow to share code among developers working on a common feature. When a feature is implemented, it must be tested before merging it to the develop branch with a pull request. When a feature branch is merged into develop, it must be suppress from the reposiory. It is recommended that the develop branch be merged into the feature branches on a regular basis to avoid any drift.
- **master**: corresponds to the last version of stable code. The develop branch is merged in the master branch when a release is ready. Bug fixes from release branches are also merged is the master branch when useful.
- **release**: dedicated to the releases. One branch per minor version release must be created (named ***release/*** *major_minor_patch*), and a tag must be set. When a bug is fixed on a release, it should be merge is the release branch. Then a new tag is created by increasing the patch digit of the release version.
- **bug**: dedicated to the bug fix of releases (named ***bug/*** *bugID*).
<img src="./doc/images/BranchingPolicy.png" alt="Branching strategy" width="1200"/>