[Releasing] [Development] brown paper bag issue in Qt 5.6.1 packages

[Jani Heikkinen]

Hi,


To be clear: There isn't version bump in qt, it is still 5.6.1. We just re-packed the release from '5.6.1' branch with that new change for fixing QTBUG-53761 included (https://codereview.qt-project.org/#/c/162677/). In tags & packages we used 5.6.1-1 to make difference with original and updated ones & to be able to identify if user has original or re-packed version in the use. Of course we could just move v5.6.1 tag in declarative and ignore v5.6.1-1 and that's it...


But It has done this way now. Ok, if tag or something is really broken let's just correct that but otherwise just live with this now. And for the future lets just agree the way to work with this kind of 'brown paper bug issue'. In my opinion bumping version numbers and doing totally new release because of just one fix is too heavy. I think we should have a way to produce this kind of update with 'simple hot fix ' easily and quickly without re-doing whole release in case of this kind of blocker.


br,

Jani

________________________________
From: Releasing <releasing-bounces+jani.heikkinen=qt.io at qt-project.org> on behalf of Thiago Macieira <thiago.macieira at intel.com>
Sent: Wednesday, June 22, 2016 8:50 AM
To: releasing at qt-project.org
Subject: Re: [Releasing] [Development] brown paper bag issue in Qt 5.6.1 packages

On quarta-feira, 22 de junho de 2016 05:03:28 PDT Jani Heikkinen wrote:
> That's why we need to update the packages just with that one fix. And that's
> why it isn't new 5.6.2 release (in my opinion), it is just 5.6.1 + hotfix.

That's still "the next release after 5.6.1 without new features", so it's
5.6.2.

> And what comes to tag: we have used '-1' tag earlier (in enterprise
> repositories) and we didn't see any reason to change that 'hotfix' tagging

I don't care what you've done in enterprise repositories since they are not
visible and the Qt community wasn't consulted. We also have a rule that only
the Qt Project can create new version numbers, so enterprise releases need to
have a field to annotate differentiations: that's the part after the dash.

The binary packages also don't count. That's again exactly what the part after
the dash is for: it notes what the different build (release) of that
particular source code version is.

But the source packages cannot have a dash. There's no discussion to be had
here.

See also what QVersionNumber does:
 QVersionNumber::fromString("5.6.1") < QVersionNumber::fromString("5.6.1-1')
is false

> scheme. It was discussed in irc as well but at least for me no-one really
> says why '-1' pattern is wrong. There was just opinions for and against and
> because we have used '-1' tag earlier it was selected this time as well.

We have never used a dash in the version number itself. Separation for "rc"
and "beta" has never been a problem, though I'm sure many of our downstream
would have liked us to use version numbers like 5.7.90, 5.7.99, etc. in the
source for those.

> Another reason was the package naming: We have some tools which cannot
> handle 5.6.1.1 but can handle 5.6.1-1 in package names and it is better to
> use same format in the tag what is used in package names.

We have tools that can't handle 5.6.1-1, but can handle 5.6.1.1. More
importantly, we have tools that can't handle either, like the configure script,
which produces QT_VERSION.

Conclusion: both 5.6.1.1 and 5.6.1-1 are bad ideas. Let's use the correct
version number: 5.6.2.

> But if there is really some reason why v5.6.1-1 don't work and v.5.6.1.1
> would work then it is really ok for me to change the tag. But let's don't
> change that just because of opinions...

5.6.1-1 does not work in Linux packages. The part after the dash is reserved
for the distribution packages themselves, like the our binary packages as
discussed above. For example, OpenSUSE Tumbleweed currently has Qt packages
with version 5.6.0-1.1, the KDE::Qt56 repositories are providing 5.6.2-5.1,
KDE:Qt57 has 5.7.0-35.1.

That means release 1.1 of Qt's 5.6.0 source code. Traditionally, the release
number resets to 1 when a source version number changes, but is rev'ved up
whenever you make changes to the scripts that produce the packages. Like our
binaries.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

_______________________________________________
Releasing mailing list
Releasing at qt-project.org
http://lists.qt-project.org/mailman/listinfo/releasing
Releasing Info Page - Qt<http://lists.qt-project.org/mailman/listinfo/releasing>
lists.qt-project.org
To see the collection of prior postings to the list, visit the Releasing Archives. Using Releasing: To post a message to all the list members, send ...


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/releasing/attachments/20160622/8e401014/attachment.html>