Discussion: release procedure (with GIT)

[dennisguse]

With release of STL2019 (and hopefully more to come), we now should keep track of which release corresponds to which commit/branch in the Github repository.
From a GIT perspective a release is just a commit that is tagged (see https://git-scm.com/book/en/v2/Git-Basics-Tagging) and thus is easy to find.

Situation pre-STL2019:
So, far we used the dev branch to develop new features while the master branch has the accepted features.
So, far master was always behind dev residing on the same commit history.
The STL2009 commit was tagged (see https://github.com/openitu/STL/releases) and it is still in the master.

Situation with STL2019
With the release of the STL2019, we have now the situation that there is an accepted release from ITU-T.
In fact, this release did not exactly correspond to our master/dev as it contains changes in the documentation.
So, we added these changes into dev and master.
The actual issue is now that in meantime additional changes were merged into master...

Options:

1. For a new release: freeze (i.e., do not make any changes) master and dev until all requested changes are integrated into first dev and then merged into master.
   During this time, we could use a separate branch for additional development (e.g., devWhileInRelease [Best name ever!]).
   When all changes are integrated, we tag the corresponding commit in master.

2. For a new release: we branch from master on submission to ITU-T and integrate requested changes into this branch.
   When finally accepted, we tag this commit.
   During this time, master and dev can be used as usual.
   After tagging the commit on the release branch, we cherry-pick the changes to dev and merge it into master.

With regard to personal preference, I opt for Option 1 as we will then only have one commit path and it is far cleaner afterwards (on a long run).
This also assumes that we have no changes anymore to released version.
If not, we would need to go with Option 2 - but maintaining completely separated branches is quite some additional work.

For the STL2019: we could revert the added changes that are not in accepted release by ITU-T, then add the release tag, and finally add the reverted commits again.

[dennisguse]

There is another option (1.1 more or less): on submission freeze master while dev is used for normal development.
And on acceptance by ITU-T all necessary changes are added to master, a release is tagged, and then changes from dev are put into master (also freezing it).

[ludomal]

@dennisguse, @simaocampos, @maadolph - I realized we have not tagged STL2019, after all this time. I have reviewed the different options proposed above (thanks @dennisguse), and I think Option 1 would work well.

I have created a small diagram to make sure we are all on the same page:

[dennisguse]

@ludomal Sounds good!
I guess, we should rename master to main.