[Development] [Announce] Qt 4.8.4 released
Hi! somehow my previous mail didn't make it. So better late then never: I'm happy to announce that Qt 4.8.4 has just been released. See the blog on http://blog.qt.digia.com/blog/2012/11/29/qt-4-8-4-released/ and the changes file at http://qt.digia.com/Release-Notes/Release-Notes-Qt-484/ for details. Thanks go to everybody who has contributed to it! Cheers, Lars ___ Announce mailing list annou...@qt-project.org http://lists.qt-project.org/mailman/listinfo/announce ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Releasing] Bumping Qt 4 version to 4.8.5
On Tue, Dec 04, 2012 at 07:53:41AM +, Vladimir Minenko wrote: After yesterdays release we are planning to bump the Qt 4 version to 4.8.5. Guys, would it be a big problem to wait with this until the end of this week? We are releasing the final NDK this week and a change in the version is will cause trouble. We will definitely revert it internally which will bring Qt in the NDK out of sync with the upstream Qt... i don't get your reasoning. the branch already has additional commits, so whatever you release, it's *not* stock 4.8.4, and you are doing everyone a disservice claiming it. and once you accept that it's 4.8.4-rim, it doesn't matter what the version in the repository says, as you need to change it anyway. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New playground project
On Nov 29, 2012, at 10:47 AM, Jarkko Laitinen jlaiti...@gmail.com wrote: Hi, I sent a message to this mailing list a while ago and got couple of responses. I have developed QCloud, an API that enables integration of Amazon S3 and Windows Azure to Qt applications. The project has been done in conjunction with Digia and Sami Makkonen mentioned this in his presentation at Developer Days in Germany. I have talked with Sami and the next logical step is getting the project to playground so that it could be developed further. The API is tested, but there is still stuff to do. I think this is a good Idea. Following http://qt-project.org/wiki/Creating-a-new-module-or-tool-for-Qt, could you create a task with the necessary data (project name: qtcloud and a description). Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt 5 RC Testing
Hello, There are new packages available for testing on Linux and Mac. We're working on Windows installer package. http://releases.qt-project.org/digia/5.0.0_rc1/backups/2012-12-04-363/ Please feel free to test them. We will appreciate your feedback. Known issues are to be found here: http://qt-project.org/wiki/Qt500RC1KnownIssues Best regards, /Rafal From: Motyka Rafal Sent: Monday, December 03, 2012 12:34 PM To: development@qt-project.org Subject: Qt 5 RC Testing Hello, Qt 5 RC release testing continues. We would like to kindly ask the Qt Community for help by testing the new packages. 1. Installer packages are available here: http://releases.qt-project.org/digia/5.0.0_rc1/backups/2012-12-03-362/ http://releases.qt-project.org/digia/5.0.0_rc1/backups/2012-11-29-358/ 2. We're still working to fix issues. The list of known issues and workarounds: http://qt-project.org/wiki/Qt500RC1KnownIssues If you find anything that is not already there, please feel free to update the wiki with your findings. 3. Qt bug reports (in https://bugreports.qt-project.org/) should be reported with Affects Version/sRequired = '5.0.0 RC 1'. 4. If there are issues you think must be fixed before we can have a meaningful the release, please ensure that it is marked as required for QTBUG-27426 - Qt 5.0 Final release tasks. https://bugreports.qt-project.org/browse/QTBUG-27426 includes known bugs. 5. Documentation issues are covered by https://bugreports.qt-project.org/browse/QTBUG-27512 6. There is a form http://testresults.qt-project.org/forms/release-testing/ to be used to communicate the testing results. Please feel free to use it. 7. If there is a need for discussion, let's do that on releas...@qt-project.org or on irc: #qt-releases on Freenode. Thank you. Best regards, /Rafal Rafal Motyka QE Engineer Digia, Qt Email: rafal.mot...@digia.commailto:forename.surn...@digia.com Mobile: +47 95005389 http://qt.digia.com Qt Blog: http://blog.qt.digia.com/ Qt Facebook: www.facebook.com/qt Qt Twitter: www.twitter.com/qtcommercial -- PRIVACY AND CONFIDENTIALITY NOTICE This message and any attachments are intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error, please contact the sender immediately and delete the message and any attachments accompanying it. Digia Plc does not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message. - ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] branch commit policy (Was: Branches)
On Mon, Dec 03, 2012 at 04:29:24PM +, Knoll Lars wrote: Dev is the branch where you can land anything that's supposed to go into 5.1. The following policies apply: Stable: This branch will be the basis for Qt 5.0 and subsequent patch level releases. The following policies apply here: as clearly some people are *already* doing it wrong, i'd like to remind everyone of the obvious other side of branching: merging. in all clarity: we have a merge-only policy between long-living branches in the same repository. there are *no* cherry-picks (you get slapped hard for every single one). submit fixes to the lowest applicable branch (generally stable, later release for release-critical problems) and wait for them being forward-merged to dev by a qualified merge master. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] branch commit policy (Was: Branches)
On 04.12.2012 12:28, Oswald Buddenhagen wrote: On Mon, Dec 03, 2012 at 04:29:24PM +, Knoll Lars wrote: Dev is the branch where you can land anything that's supposed to go into 5.1. The following policies apply: Stable: This branch will be the basis for Qt 5.0 and subsequent patch level releases. The following policies apply here: as clearly some people are *already* doing it wrong, i'd like to remind everyone of the obvious other side of branching: merging. in all clarity: we have a merge-only policy between long-living branches in the same repository. there are *no* cherry-picks (you get slapped hard for every single one). submit fixes to the lowest applicable branch (generally stable, later release for release-critical problems) and wait for them being forward-merged to dev by a qualified merge master. A merge-diode ;) Peter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Releasing] Bumping Qt 4 version to 4.8.5
On terça-feira, 4 de dezembro de 2012 11.56.39, Oswald Buddenhagen wrote: On Tue, Dec 04, 2012 at 07:53:41AM +, Vladimir Minenko wrote: After yesterdays release we are planning to bump the Qt 4 version to 4.8.5. Guys, would it be a big problem to wait with this until the end of this week? We are releasing the final NDK this week and a change in the version is will cause trouble. We will definitely revert it internally which will bring Qt in the NDK out of sync with the upstream Qt... i don't get your reasoning. the branch already has additional commits, so whatever you release, it's *not* stock 4.8.4, and you are doing everyone a disservice claiming it. and once you accept that it's 4.8.4-rim, it doesn't matter what the version in the repository says, as you need to change it anyway. I agree with Ossi. Your request doesn't make sense, Vladimir. If you're taking the latest 4.8 branch instead of the released packages, you're in for a lot more trouble. I suggest creating your own branch based on 4.8.4 and cherry-picking any commits you need into it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] VNC and Qt5
On terça-feira, 4 de dezembro de 2012 10.21.55, Salomon, Florian wrote: Hello everybody, i needed to know if and when VNC-support is planed for Qt5? What do you want supported? Do you want to be able to see regular Qt applications when using a VNC server on X? If so, that should be supported already. Do you have a specific complaint? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Releasing] Bumping Qt 4 version to 4.8.5
On Tue, Dec 4, 2012 at 5:21 PM, Konstantin Tokarev annu...@yandex.ruwrote: There's no point in keeping separate branch purely for tags. It is just an unnecessary overcomplication. Actually, there is: it allows you to continue working in stabilization branches, then discard those changes (i. e. never release them into master or the -releases branch) and it helps overcome the lack of git tags support in some continuous integration systems. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Releasing] Bumping Qt 4 version to 4.8.5
04.12.2012, 21:02, Pau Garcia i Quiles pgqui...@elpauer.org: On Tue, Dec 4, 2012 at 5:21 PM, Konstantin Tokarev annu...@yandex.ru wrote: There's no point in keeping separate branch purely for tags. It is just an unnecessary overcomplication. Actually, there is: it allows you to continue working in stabilization branches, then discard those changes (i. e. never release them into master or the -releases branch) This is something you are supposed to do in topic branches, forked from stabilization branch. Also, you have git revert for extreme cases. and it helps overcome the lack of git tags support in some continuous integration systems. Sounds weird, like it was continuous integration system without support for branches. -- Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Releasing] Bumping Qt 4 version to 4.8.5
On Tue, Dec 4, 2012 at 6:26 PM, Konstantin Tokarev annu...@yandex.ruwrote: 04.12.2012, 21:02, Pau Garcia i Quiles pgqui...@elpauer.org: On Tue, Dec 4, 2012 at 5:21 PM, Konstantin Tokarev annu...@yandex.ru wrote: There's no point in keeping separate branch purely for tags. It is just an unnecessary overcomplication. Actually, there is: it allows you to continue working in stabilization branches, then discard those changes (i. e. never release them into master or the -releases branch) This is something you are supposed to do in topic branches, forked from stabilization branch. Also, you have git revert for extreme cases. Our workflow is a bit different, we have QA, marketing and other stakeholders who may decide, after 3 weeks of QA validation, that the version to release is not the tip of the -stabilization branch but an older version (we then update -release with some older version from -stabilization). You could say release-3.1-stabilization and release-3.1-releases are topic branches; we don't. and it helps overcome the lack of git tags support in some continuous integration systems. Sounds weird, like it was continuous integration system without support for branches. Welcome to the wonderful world of CruiseControl.NET. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Releasing] Bumping Qt 4 version to 4.8.5
It's not difficult to understand. For example, 4.8.4 was released, it means v4.8.4 was taged. All later changes after that in 4.8 branch don't belong to 4.8.4. They must be part of next release of 4.8 branch, obviously it is 4.8.5. So the version bumps to 4.8.5 should happen just after 4.8.4 released. And 4.8.4 is released, it must be stable enough for many platforms which current CI has covered. You could branch a 4.8.4-BB from 4.8.4, for example. Maybe it just missed some fixes which BB10 need, you guys still could commit them into 4.8 branch to get them passed in CI, it means they are tested for other platforms. Then you can cherry pick them into 4.8.4-BB and test on device, until you are satisfied about 4.8.4-BB to release. That's my understand. BTW, Sorry for top reply, I am still using the ugly web mail client. Regards, Liang From: development-bounces+liang.qi=digia@qt-project.org [development-bounces+liang.qi=digia@qt-project.org] on behalf of Vladimir Minenko [vmine...@rim.com] Sent: Tuesday, December 04, 2012 7:21 PM To: releas...@qt-project.org; development@qt-project.org Subject: Re: [Development] [Releasing] Bumping Qt 4 version to 4.8.5 I agree with Ossi. Your request doesn't make sense, Vladimir. If you're taking the latest 4.8 branch instead of the released packages, you're in for a lot more trouble. I suggest creating your own branch based on 4.8.4 and cherry-picking any commits you need into it. Ok... Well, I can also ask a good question why you bump the version to 4.8.5 before it is actually released. You probably will have a good answer, likewise I will also have a good answer why bumping the version disturbs our integration right now. But, all this does not help by the end of the day... In short, 1) we cannot wait for official 4.8.x releases and work directly on the master, 2) we have no time for manual cherry-picking into an internal branch and decided to take all commits as long as a snapshot passes our testing. As mentioned in my previous email, changing the version of Qt changes the version of the so libs, which we have to reflect while building device images. Sometimes, there is just no time for this, and an entire update of Qt in BlackBerry 10 is in danger to get stuck. We currently just cannot afford this! Fine, we will just revert that commit if needed... Anyway, we had a chance to hear about this on-time. This is good. Previously, it was rather a surprise... Cheers! -- Vladimir ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] VNC and Qt5
I don't know what he meant, but I wondering if it makes sense to create QPA plugin for VNC or rdesktop. tr3w On Tue, Dec 4, 2012 at 4:13 PM, Thiago Macieira thiago.macie...@intel.com wrote: On terça-feira, 4 de dezembro de 2012 10.21.55, Salomon, Florian wrote: Hello everybody, i needed to know if and when VNC-support is planed for Qt5? What do you want supported? Do you want to be able to see regular Qt applications when using a VNC server on X? If so, that should be supported already. Do you have a specific complaint? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ 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] Bumping Qt 4 version to 4.8.5
On Tue, Dec 4, 2012 at 11:08 PM, Thiago Macieira thiago.macie...@intel.com wrote: Here's a question to the project: do we want to merge (-s ours) the releases from vendors into our official tree? And do we want their tags too? Speaking with my Mer Project (/Jolla) hat on: I don't think direct merges would work, at least for our case. There are sometimes changes we have that cannot be upstreamed. For instance, we (still) have MeeGo's XInput2 patch against Qt 4, which we can't apply, thanks to the rules of the branch. We also have a bunch of changes that would equate to a QtQuick 1.2, and I'm guessing that isn't really acceptable upstream (even if it would probably be nicer both for the users of Qt, and for me when looking at our large patch delta...). We also don't really do tagging, as our release process happens separately from the git tree. I maintain our packaging as the upstream tarball plus a set of patches, as I'm firmly convinced that there's less bus factor there than distributing a massively hacked up tarball. I do have a git branch published (https://github.com/rburchell/qt), but like the warning on the tree says, it can (and is) rebased often. I do encourage (and participate in) pushing stuff upstream where that is possible though, and some of our changes (like allowing configuration of QApplication's startDragDistance property) might be useful to push, but I'm unconvinced that our current approach (an environment var) is the best possible solution - but haven't been able to think of a better one, either :-). ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
