> This was discussed earlier, and we were thinking about using a branch.
> It
> was decided that we will try without. The basic idea is that at any
> time
> the code should be good to use. Naturally it is not always so, thus we
> may
> need to take another try.
>
> We have nothing against using a branch, but it is not mandatory either.
> At
> least not for patch releases.
>
> Tag we will naturally do, so that it is easy to know what is the exact
> release version.
>
Summary of an IRC discussion:
Currently this SHA is being tested (logically it is 4.8.1-rc1)
If all goes well, we can just release that SHA and tag it with v4.8.1
If there is a blocking defect (e.g. serious regression from v4.8.0), then we'd
need to fix that.
However, other changes have already happened on the 4.8 branch, giving this
situation:
(rc1)-o-o-o-o-o-o-fix
The intermediate commits (-o-) are ordinary bug fixes that can go to 4.8.2.
Hopefully they don't introduce regressions themselves, but it is possible.
The choice then is whether to take the intermediate commits and restart testing:
(rc1)-o-o-o-o-o-o-fix(rc2)
Or to create a 4.8.1 release branch, cherry pick the fix, and continue testing:
(rc1)-o-o-o-o-o-o-fix
\
fix(rc2)
Either way, whatever rc is good enough to release is what gets released and
tagged.
The final situation looks like one of these:
(rc1)-o-o-o-o-o-o-fix(rc2)-o-o-o-o-o-o-fix(v4.8.1)
Or:
(rc1)-o-o-o-o-o-o-fix-o-o-o-o-o-o-fix
\
fix(rc2)-fix(v4.8.1)
The best case is that rc1 has no showstoppers and we can just release it.
The opinion among those who were in the irc discussion was that we should
create a branch and cherry pick if there are showstoppers.
It was pointed out that branches in git are cheap, so we could have created a
4.8.1 branch already (with no commits, except the HEAD points at the SHA being
tested). However, branches in gerrit may not be so cheap as only a few people
can create branches on the server.
________________________________
Subject to local law, communications with Accenture and its affiliates
including telephone calls and emails (including content), may be monitored by
our systems for the purposes of security and the assessment of internal
compliance with Accenture policy.
______________________________________________________________________________________
www.accenture.com
Subject to local law, communications with Accenture and its affiliates
including telephone calls and emails (including content), may be monitored by
our systems for the purposes of security and the assessment of internal
compliance with Accenture policy.
______________________________________________________________________________________
www.accenture.com
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
