[Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Lisandro Damián Nicanor Pérez Meyer]

On lunes, 21 de noviembre de 2016 15:57:06 ART Thiago Macieira wrote:
> On terça-feira, 22 de novembro de 2016 01:06:00 PST André Pönitz wrote:
> > I also said that packagers (i.e. people like you) *are* affected, but I
> > claimed the way they are affected is not fundamentally different from
> > what happens if the packages in question uses any other library that
> > doesn't guarantee BC, or - in case they have similar BC promises like Qt
> > - what happens when there are jumps in major versions.
> 
> Fundamentally, no. But the important difference is the bottleneck.
> 
> I remember in the MeeGo days when building MeeGo with OBS spent an hour on a
> very beefy machine compiling Qt, with most of the resources in the OBS farm
> unused because nothing else could be built yet. With Qt 5 and our split
> packages, this lessens because only qtbase is the bottleneck.

As long as qtbase's private headers do not change. I guess in that case one 
who knows exactly what would affect will just rebuild the necessary parts, the 
rest of us need to get all the stuff rebuilt (17 submodules? maybe they are 
more right now).
 
[snip]
> I can't think of anything that would be worth the major headache that
> breaking BC more often than once every 4 years would cause. And note I'm
> not talking about breaking SC.

And if this can be coupled with an upstream-made SONAME like 5 to 5abi1... 
well, I guess once in 4 years is not that much.

-- 
Never attribute to malice that which is adequately explained by stupidity.
  http://en.wikipedia.org/wiki/Hanlon's_razor

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20161121/99df9cdd/attachment.sig>