--===============1475317972==
Content-Type: multipart/signed;
  boundary="nextPart6578937.Ei4rS2v0aA";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart6578937.Ei4rS2v0aA
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Alle 01:05, gioved=C3=AC 25 gennaio 2007, Seb Ruiz ha scritto:
> On 25/01/07, Angelo Naselli <anaselli@linux.it> wrote:
> > > +        KDE_PKG_CHECK_MODULES(LIBGPOD, libgpod-1.0 =3D 0.4.2, have_l=
ibgpod=3Dyes,have_libgpod=3Dno)
> > Seb shouldn't it be >=3D 0.4.2? I mean I hope it will build also for fu=
ture releases...
>=20
> Possibly, except there aren't libgpod releases often, and i don't want
> to risk another breakage in API again, as is liable to happen with the
> library.
>=20
> I rationale was that there are more kipi releases than libgpod so it
> should be easy to change later if necessary.
Well, the only exception I see is, suppose we loose compatibility in
0.5.0 for instance and there is at least one release in the middle let's say
0.4.3, that means changing configure.in.in for 0.4.3 and again for 0.5.0.
OTH we could change it only for 0.5.0 (fixing the compatibility and putting=
 >=3D 0.5.0)
Worst case is the same of course, since we should change configure.in.in
every release of libgpod.

Just my 2 =E2=82=ACcents,
	Angelo
=20

--nextPart6578937.Ei4rS2v0aA
Content-Type: application/pgp-signature

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

iD8DBQBFuHVtqEs9DA4DquARAownAJ0UCLG3lRfnZXbv6eMUebbQs9NHSwCgkDIl
1Gd7ZfeGMkEanTcY+gGw5Rg=
=zG4H
-----END PGP SIGNATURE-----

--nextPart6578937.Ei4rS2v0aA--

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

_______________________________________________
Kde-imaging mailing list
Kde-imaging@kde.org
https://mail.kde.org/mailman/listinfo/kde-imaging

--===============1475317972==--