# ARF005

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)

## ETSI ISG ARF Sharepoint
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"/>