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

[Thiago Macieira]

On quarta-feira, 22 de junho de 2016 06:28:12 PDT Jani Heikkinen wrote:
> Hi,
> 
> 
> To be clear: There isn't version bump in qt, it is still 5.6.1.

Are the source packages the same? No? Then it's a new version.

> 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...

We could do that, yes:
 * no new qtdeclarative source package
 * cherry-pick the patch to the tree used for the binaries, release
 * update the binary relase version

I just think it's a bad idea and would cause confusion too.

But I'm asking that we Do The Right Thing, instead of trying to find the 
solution with the least amount of effort. We own up to our mistakes and then 
we fix the correctly.

> 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'.

Let's agree on no more "brown paper bag fixes". Let's not rush into more 
mistakes. This only happened because we tried to find the solution with the 
least amount of effort instead of doing the proper, established way of 
creating new releases.

> 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.

If we have a light-weight procedure, great, let's use it.

But we don't. And creating one the moment we need a quick fix is a bad idea, 
because we're going down untested paths and creating more problems in the 
process, as the current case has shown.

I think we should have a light-weight procedure. Let's investigate it when we 
have the time to do it.

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