--===============0047033363==
Content-Type: multipart/signed;
  boundary="nextPart3121576.FHQzsB9kPg";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart3121576.FHQzsB9kPg
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hello,

On tre=C4=8Diadienis 04 Rugpj=C5=ABtis 2010 15:09:32 Lubos Lunak wrote:
> fact exactly the opposite. They both state that some libraries, by design,
> do not keep binary compatibility, and that when a change happens, soname
> should be changed.

The latter is exactly my point. libkonq 4.5 is BIC in comparison with libko=
nq=20
4.4 and soname was NOT bumped (when should have). So what is opposite there=
 to=20
my arguments?

> > In this case, our arguments were apparently discarded because "making an
> > exception for libkonq doesn't make that much sense".
> =20
>  "to me" is missing at the end of that sentence. And, while I'm at it, the
> consequent "any other opinions?" is missing too.

Do I decide what ends up in tarballs? No. Things which do not make much sen=
se=20
are typically not done. So conclusion is that nothing would have been done =
wrt=20
kdebase.

Given that there is still a week until 4.5.0, we may find all those BIC cas=
es=20
and fix them in 4.5 by bumping soname where needed. Would there be any=20
objections to that? I think this question is on-topic for release-team ML.

> > I admit it may be a
> > bit late as we do not package pre-releases nowadays (which may be our
> > fault but that's the way it is for now). Therefore, I cannot be in
> > supervisor position for these things until it is "too late" nor anybody
> > would listen to me.
>=20
>  Oh, poor you. But in case you'll get over this attitude and will be
> interested in fixing the problem, you've been told where the right place =
to
> discuss the problem is.

Thank you for suggestion. Maybe I will try again. Though even if you do not=
=20
agree, this has already been brought up on that list a couple of times befo=
re=20
and I can't say that situation has improved much over time. Yes, libkonq ha=
s=20
not broken BC during 4.x cycle before, but many others non-kde(pim)libs did=
=2E=20
In neither case soname was bumped with a good exception of libplasma when i=
t=20
was in workspace and moved to kdelibs (libplasma.so.{1,2,3}).

It's probably that the topic is not important or considered as not worth th=
e=20
extra effort by majority of developers, so I don't expect situation to impr=
ove=20
greatly despite conclusion on k-c-d. It's not me, you or release-team who c=
an=20
fix all cases each release. What's more, I'm also afraid that when pushing =
too=20
hard people might start doing otherwise for the sake of extra safety - bump=
=20
soname in advance as soon as trunk opens without checking if changes are BC=
 or=20
not. Tracking BC is not an easy task.

=2D-=20
Modestas Vainius <modestas@vainius.eu>

--nextPart3121576.FHQzsB9kPg
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEABECAAYFAkxZjtgACgkQHO9JRnPq4hTFSACg9lPpND6LZJrk9BhoReb0n8Hq
MMwAoLQkjWaFMzeD1gTf+hYSWm+kb6x/
=OCHE
-----END PGP SIGNATURE-----

--nextPart3121576.FHQzsB9kPg--

--===============0047033363==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

--===============0047033363==--