--===============0612026709==
Content-Type: multipart/signed;
  boundary="nextPart7273601.yh3cY8Um8B";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart7273601.yh3cY8Um8B
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On Sunday 18 July 2010 19:28:13 Andreas Pakulat wrote:
> On 18.07.10 16:10:52, Julian B=E4ume wrote:
> > I thought about a better way handling the plugin-version entry in the
> > desktop files. In my understanding, this version string is used to force
> > a rebuild of each plugin after some binary-incompatible change has been
> > made. This will also trigger API-changes to be applied, since during
> > rebuilding, the plugins with incompatible API won't compile.
> >=20
> > In kdevplaform, there is a script to update the desktop files. I've
> > created some cmake scripts to handle this automatically during
> > configure-time. For now, I am getting the version string out of the
> > kdevplatform/interfaces/iplugin.h file into a cmake variable and after
> > that I use cmake's configure_files function to generate the desktop
> > files. The parsing of iplugin.h seems a bit hackish to me, so I'd
> > propose to export the plugin version as a cmake variable from the
> > FindKDevPlatform.cmake file, that gets installed along with the other
> > development files.
>=20
> Personally I disagree with that, the version number shouldn't be changed
> in the .desktop files automatically. This should always be a manual
> action that the repsonsible developer of the plugin should do.
Okay, you got a point here :) I totally agree, that the maintainer should b=
e=20
aware of what is happening.

> Increasing the plugin version may also be done as part of a behavioural
> change (where the API stays the same) and in such cases you really don't
> want plugins that haven't been adjusted loaded into a running app as it
> may cause undefined behaviour.
Did this happen, yet? I think, this case is somewhat unlikely but of course=
,=20
it can happen. So after thinking about that a little bit, doing this=20
automatically doesn't seem to be a good idea any longer.
=20
> The plugin version declares a dependency of the plugin onto a specific
> runtime version of kdevelop/kdevplatform and hence this dependency
> shouldn't be automatically generated.
Okay, but IMHO there should be a way to better support developers and=20
maintainers using the PluginController. I thought a bit about that. What ab=
out=20
allowing plugin maintainers to define a set of "working versions?" (i.e. mo=
re=20
then only one, since it has to be an exact match) At least for us, it's mos=
t=20
likely that an update of the version won't break anything within most of ou=
r=20
plugins. We are at least 2 developers using different versions of KDevelop =
and=20
therefor have different versions of KDevPlatform installed. This has been=20
working okay, so far, I just thought, that we need to do something about th=
e=20
patches, each of our developers has to maintain to have the correct version=
=20
number within the desktop files. Especially when it would work with other=20
Versions, also.

Beside this, we are getting along very good with the KDevPlatform libs and=
=20
it's a great help to use it. May be, we can come up with a solution, that=20
works a bit better, than it's now. IMHO, this can't be so hard ;)

bye then
julian

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)

iQEcBAABAgAGBQJMQ+AQAAoJEIPPyJ5jLHS/erYH/jdl36dpEKuFYsxgaDPUtn7e
Q0Jii/7+ewfvN7lC0Z3Xj1GgBVfx1kk8gRN9qEO/jsQbkfJd/f8oetTyyLvilClH
M3I5LB16l4CnYto4dlrbPedrgNMBYAhAF/Kf/Ngubr+oOwI/4nWEhmTgD+YFp0ec
qer8HO0ai5tjwJkMdxBW/iPxoTNr/tyhTKUZh8BHX99EjGop1Vp9lAYA/HC+fb2L
PTiesa1+czfypACLytu1NoFPx8G8ix4WXPOnlu9i9ljq2oxLnUC3icOQAmodB3Ak
+Nx81XXagQKCFlp13ycvUSyaKzoKsI8xmWG4St5DhAz22j2vx/4K46H3XHWfEYQ=
=rjkq
-----END PGP SIGNATURE-----

--nextPart7273601.yh3cY8Um8B--


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

-- 
KDevelop-devel mailing list
KDevelop-devel@kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel

--===============0612026709==--