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. -- https://mail.python.org/mailman/listinfo/python-list
