[Releasing] qtwebkit 5.5.2 or 5.6.0

Knoll Lars Lars.Knoll at theqtcompany.com
Tue Dec 1 09:11:47 CET 2015


On 30/11/15 18:23, "Releasing on behalf of Thiago Macieira" <releasing-bounces at qt-project.org on behalf of thiago.macieira at intel.com> wrote:



>On Monday 30 November 2015 12:49:49 Lisandro Damián Nicanor Pérez Meyer wrote:
>> On Monday 30 November 2015 13:13:10 Frederik Gladhorn wrote:
>> [snip]
>> 
>> > As for source tarballs I think we have so far not considered producing
>> > tarballs as Jani writes, why do you see the necessity?
>> 
>> Distributions who have lots of apps still using qtwebkit will simply love
>> these tarballs. As a last resort we can create them from git but still
>> better if we can use an upstream tarball.
>
>That is a good reason. The other is the fact that our tarballs are not simple 
>equivalents of git archive, so there's some post-processing left-over that 
>some users will not realise they need.
>
>Asking people to download from Git will lead them to download from GitHub:
>	https://github.com/qtproject/qtwebkit/archive/dev.zip
>
>And we know the build from a git archive export does *not* *work*.
>
>Please create the tarballs and upload them. They don't have to be built to 
>binary and they don't have to be part of the joined source code, but they will 
>need to exist.
>
>And we'll need to keep releasing every time that we change qtbase in such a 
>way that breaks the build of those modules.

The reason for removing modules is to stop having to worry about them. Like this we’ll save very little work in our packaging/releasing. Actually this would be some extra work, as the packages would fall outside the regular workflow.

In addition, this conflicts with your message on development about keeping compatibility on the build system level. If we stop supporting a module, we shouldn’t have to do any more releases on it. 

But this clearly shows that we need to simplify our source packages creation to a git archive call (without further post processing). We haven’t done it so far because people will then need additional build tools (esp. on Windows). But given this, we need to get to that state rather soon, to avoid these kind of problems.

Cheers,
Lars



More information about the Releasing mailing list