use cmake to support kdevelop plugin versioning

[Julian Bäume]

On Sunday 18 July 2010 19:28:13 Andreas Pakulat wrote:
> On 18.07.10 16:10:52, Julian Bäume 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.
> > 
> > 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.
> 
> 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 be 
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, 
it can happen. So after thinking about that a little bit, doing this 
automatically doesn't seem to be a good idea any longer.
 
> 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 
maintainers using the PluginController. I thought a bit about that. What about 
allowing plugin maintainers to define a set of "working versions?" (i.e. more 
then only one, since it has to be an exact match) At least for us, it's most 
likely that an update of the version won't break anything within most of our 
plugins. We are at least 2 developers using different versions of KDevelop and 
therefor have different versions of KDevPlatform installed. This has been 
working okay, so far, I just thought, that we need to do something about the 
patches, each of our developers has to maintain to have the correct version 
number within the desktop files. Especially when it would work with other 
Versions, also.

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

bye then
julian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100719/6d13049b/attachment.sig>