Adopting semantic versioning in trunk based development with Python

[dcs3spp]

On Thursday, 11 April 2019 17:33:04 UTC+1, dcs3spp  wrote:
> Hi,
> 
> Hoping posting this in the correct place...Apologies if not....
> 
> I am trying to understand how to use semantic versioning with trunk based development for a Python project. Has anyone had any experience of adopting a trunk based development with semantic versioning for packages?
> 
> I store the semantic version in version.py :__version__ which gets included in setup.py
> 
> On the trunk (main) version.py:__version__ would be 1.0.0-SNAPSHOT and on the CI server each build would append the build number, e.g. 1.0.0.1234-SNAPSHOT. A changelog would initially be empty for the semantic version number on the trunk (main).  
> 
> When ready to release a release branch would be created *release-1.0.x* and any fixes, features would be cherry-picked from main. A gitlab CI job would still run tests for commits on branches named *release-*. The release branch may be tagged, e.g. 1.0.1, 1.0.2 etc. until the release stabilises. This would bump the version number in version.py.
> 
> The changelog could be finalised on the release-branch, however this would mean that it would have to be merged back to trunk(main). version.py would also presumably have to be merged back to trunk after it is has been bumped following hotfixes on the release branch. Is a merge from release to trunk(main) acceptable in trunk based development for changelog and version files only?
> 
> The problem would be if a new release, e.g. 1.1.0-SNAPSHOT was then prepared for while release branch 1.0.x was still active then the version number would be out of synch between trunk and release??
> 
> How is this managed with trunk based development approach?
> 
> Kind regards
> 
> dcs3spp

PS, error in my original question where I stated features cherry picked from main. Typo. Only fixes can be cherry picked from trunk(main) onto a release branch.