[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kopete-devel
Subject:    Re: [Kopete-devel] About 0.5 roadmap and Kopete future
From:       Martijn Klingens <klingens () kde ! org>
Date:       2002-05-30 19:56:13
[Download RAW message or body]

On Thursday 30 May 2002 21:24, Duncan Mac-Vicar Prett wrote:
> After a release everyone is excited about adding tons of features ( freeze
> break), I hope everyone can follow these guidelines when adding a feature,
> and discuss it with all the team , may be other has a better solution.

Mostly seconded, and the rest we can surely resolve...

On a related but different note, I have a technical proposal for 0.5:

If you want to add APIs to libkopete, or change existing APIs, please consider 
one of the following approaches, but don't break most of kopete compilation 
for a considerable time like with the KMM branch unless ABSOLUTELY necessary 
and discussed and approved here:

- Convert all plugins and test them if you change APIs, and commit in one
  burst. Discuss API changes on the list.

- Keep a downwards compatibility layer while developing new stuff. Add a
  method bool canDoMyFeature() in libkopete with a default implementation that
  returns false and develop and test your code in a single plugin where the
  code returns true instead. If the plugin doesn't support the requested API,
  use the 0.4 code, and only call the new API if there is support. After your
  API is more or less mature, ask others to port, or port the other plugins
  yourself. Once all plugins are over remove the compatibility layer
  altogether. As this still affects the API, you still need to discuss here.

- Use any other method that is non-intrusive to existing code, and by all
  means keep HEAD in a compilable and running state! It is HEAD, so stability
  may be flaky, but all plugins should at least compile and run. Changes in
  the API that affect other plugins need to be discussed BEFORE committing, so
  appropriate precautions can be taken and plugin maintainers can help porting
  more quickly and easily.

Whatever you do inside the plugins is mostly your own business, but keep the 
following guidelines in mind:

- If it is useful for more than one plugin, develop it generic, so it can be
  moved to libkopete as soon as it's more or less stable and mature.

- If it adds highly technical feature bloat, consider hiding it far away in an
  advanced tab. This can not always be done in the current framework, but
  where possible, please consider it.

Comments, flames or other responses?

Martijn

_______________________________________________
Kopete-devel mailing list
Kopete-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/kopete-devel
[prev in list] [next in list] [prev in thread] [next in thread]