This provide specification for using git submodule
& branching for simplified/naive package system.
You can use your git repository as submodule inside another one. One reason for that is using development approach specified by this document.
You have combination of these problems:
- internal library
- library with minimal/small/no so big need for updating ~ technically done, just support
- no (stable) developer team for given library
git submodule
s give you:
- way to provide such library
- update library is just
git pull
- developer using library has ability to create fix/change from inside his/her repository as a new PR request
- ↘this have to be tested (as „non LTS” version) in project where the library is used
- ↘it can make PR aproving quicker
To allow library be used as submodule and make library „working”/sustainable you should follow:
- There are reserved LTS (long term support) branches
- default branch (main/master) = the latest version
- branch with prefix lts_: lts_a, …, lts_z, lts_aa, …
- The default (main/master) branch contains the latest version of the library code
- When change is needed (user):
- try existing non-lts branch for your lts branch
- or
- create new branch with patternt source-unique (source= name of the lts branch, unique= not used identificator to prevent colision)
- create Pull Request
- automatically non-lts ⇒ hast to be considered when testing parent library/app
- commits
- Branches
lts\_*
are created from default branch (automatically after PR is merged, on request, …) - Consolitation of PRs ⇒ new library version update:
- Contact coleagues about tests
- Additional testing - reimplementation (prefering backward support)
- Submit PR + delete branch
For make statement that repo follows these instruction use:
[![LTS+sub-branches](https://img.shields.io/badge/submodule-LTS+sub--branches-informational?style=flat-square&logo=git)](https://github.com/IndigoMultimediaTeam/lts-driven-git-submodules)