[Releasing] Deprecation - we are doing that wrong

Knoll Lars Lars.Knoll at theqtcompany.com
Thu Feb 4 12:31:56 CET 2016

On 04/02/16 12:23, "Releasing on behalf of Oswald Buddenhagen" <releasing-bounces at qt-project.org on behalf of oswald.buddenhagen at theqtcompany.com> wrote:

>On Thu, Feb 04, 2016 at 11:09:52AM +0000, Knoll Lars wrote:
>> We know that these modules are still in use in some places, and that
>> Linux distributions and some of our customers would appreciate some
>> tar ball that compiles and works against 5.6, so that they can update
>> their stack. To accommodate for this, we can spend a bit of time to
>> get the 5.6 branch of these modules passing in CI. That can be done
>> completely independent of our packaging and release process, and
>> doesn’t have to happen at the same time. Once we have a version that
>> passes CI, we take the source tar ball created by CI, put that onto
>> our ftp server under 5.6/unsupported/qtquick1.tgz (or similar). 
>that makes no sense. building and maintaining this parallel
>not-quite-release infrastructure would be more effort than keeping it
>building and dragging it along the normal releases. that's how we
>arrived at the previous conclusion to "soften" the removal.

I don’t agree. I want to get rid of things that make it harder for us to release Qt. That’s what is IMO most important, given how we have fight to get releases out.

And I don’t think there’s a lot of effort involved, as the CI can test these modules independently. Actually we might save ourselves at some work, as we separate the problems. At least we will have a lot less pressure with that work, as it doesn’t block anything critical.


>i don't think we should spend effort on keeping the autotests passing.
>we can include them in the state builds, so willing parts of the
>community can monitor it, but that's a far as i would go beyond keeping
>it building.
>Releasing mailing list
>Releasing at qt-project.org

More information about the Releasing mailing list