Re: [Development] [Releasing] Qt 4.8.1 open source release date approaching..
Hi All, Although late for 4.8.1 this is a good discussion to have. I think the key question that needs to be answered is: Do we aim to have a model where it is typically ok to take always the latest that exists in the repository? If the answer is yes, agreeing not to branch will support the goal. Drawback is the fact that putting a single fix of top of otherwise working set will not be feasible. For a patch release it should not be a significant drawback. And as all things that go in are bug fixes anyway it should always be ok to have a few more. Certainly for the minor releases we need to have a branch in order not to hurt development of new things while getting into release maturity. But for patch releases it should be feasible to keep release maturity at any time. Yours, -- Tuukka Turunen Director, Qt Commercial RD Digia Plc Piippukatu 11, 40100 Jyväskylä, Finland Visit us at: www.digia.com or qt.digia.com On 12.3.2012 19.45, shane.kea...@accenture.com shane.kea...@accenture.com wrote: On Fri, Mar 09, 2012 at 07:16:24PM +, ext shane.kea...@accenture.com wrote: (rc1)-o-o-o-o-o-o-fix-o-o-o-o-o-o-fix \ fix(rc2)-fix(v4.8.1) this is no option, because it loses the tag from the history. traditionally we have merged back the release branch to the maintenance branch (and thus to master), which means that we have all those cherry-picks twice in the history. try to read *that*. therefore the only clean options are either a) just don't create a branch or b) if you create a branch, then apply any fixes which are supposed to be in it *only* to that branch, so it can be cleanly forward-merged. The full picture including the merge back would look like: (rc1)-o-o-o-o-o-o-fix-o-o-o-o-o-o-fix-o-o-o-M \ / fix(rc2)-fix(v4.8.1)-. The tag has to be on the branch (if there is a branch), otherwise git checkout v4.8.1 doesn't give the same thing as the release tarball. Tools that show the history including branches (e.g. gitk) would give a picture like what's above, git log will show the cherry picks twice in the history. The history is unreadable for v4.8.0 because of the 7 parallel staging branches, but displaying two parallel branches (4.8 and 4.8.1) should be sane and readable. I believe that git log v4.8.1.. includes the commits which came in with the merge (anything on 4.8 but not on 4.8.1 branch) 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 Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Releasing] Qt 4.8.1 open source release date approaching..
On Tue, Mar 13, 2012 at 07:16:35AM +, ext Turunen Tuukka wrote: Certainly for the minor releases we need to have a branch in order not to hurt development of new things while getting into release maturity. But for patch releases it should be feasible to keep release maturity at any time. this is fallacious logic. the stable branch is created long before the minor release, so the commits going into the branch are only fixes as well. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Releasing] Qt 4.8.1 open source release date approaching..
On Fri, Mar 09, 2012 at 07:16:24PM +, ext shane.kea...@accenture.com wrote: (rc1)-o-o-o-o-o-o-fix-o-o-o-o-o-o-fix \ fix(rc2)-fix(v4.8.1) this is no option, because it loses the tag from the history. traditionally we have merged back the release branch to the maintenance branch (and thus to master), which means that we have all those cherry-picks twice in the history. try to read *that*. therefore the only clean options are either a) just don't create a branch or b) if you create a branch, then apply any fixes which are supposed to be in it *only* to that branch, so it can be cleanly forward-merged. The full picture including the merge back would look like: (rc1)-o-o-o-o-o-o-fix-o-o-o-o-o-o-fix-o-o-o-M \ / fix(rc2)-fix(v4.8.1)-. The tag has to be on the branch (if there is a branch), otherwise git checkout v4.8.1 doesn't give the same thing as the release tarball. Tools that show the history including branches (e.g. gitk) would give a picture like what's above, git log will show the cherry picks twice in the history. The history is unreadable for v4.8.0 because of the 7 parallel staging branches, but displaying two parallel branches (4.8 and 4.8.1) should be sane and readable. I believe that git log v4.8.1.. includes the commits which came in with the merge (anything on 4.8 but not on 4.8.1 branch) 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 Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Releasing] Qt 4.8.1 open source release date approaching..
Hi, 2012/3/9 Salovaara Akseli akseli.salova...@digia.com: Hi, We are currently preparing testing Qt 4.8.1 open source release for next week. Exact release date is still open, until all tests are passed. And, as discussed it is possible that critical problems are found, and then we need to take another try. We are currently testing against sha1 that points to commit: 1e0021d8d9e374ae3959fcd4eac5d9e7238cbc54 Can you create a branch instead? The way it's been done traditionally (for old values of tradition) is: a. Create a 4.8.1 branch. People should be testing this branch for the release and this branch only. b. Patches can continue to go in 4.8 branch (but will only be in 4.8.2). The testing of the above doesn't need to be restarted over and over again c. If the committer in 4.8 feels his patch is supremely important and fit for 4.8.1, he pings the release dude (you) and seeks permission to put his change in 4.8.1 branch. You analyze the risk and approve/disapprove. d. Once you are ready for release, ship the 4.8.1 branch. Create a signed tag v4.8.1 with your signature. This makes sure that even if someone confidently committed stuff in 4.8.1 post-release, we still know what we shipped with. If there's another methodology in place, let me know, but the current way of sha1 based testing is not ideal. Girish ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Releasing] Qt 4.8.1 open source release date approaching..
On Fri, Mar 09, 2012 at 07:16:24PM +, ext shane.kea...@accenture.com wrote: (rc1)-o-o-o-o-o-o-fix-o-o-o-o-o-o-fix \ fix(rc2)-fix(v4.8.1) this is no option, because it loses the tag from the history. traditionally we have merged back the release branch to the maintenance branch (and thus to master), which means that we have all those cherry-picks twice in the history. try to read *that*. therefore the only clean options are either a) just don't create a branch or b) if you create a branch, then apply any fixes which are supposed to be in it *only* to that branch, so it can be cleanly forward-merged. It was pointed out that branches in git are cheap, branches are cheap is a bogus argument to start with. it's always the merging that incurrs the cost (on the human side. technically broken scms are not worth mentioning). ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
