Hi victor,
> This is a follow up on a discussion that we had today on IRC. The
> question is how much backward compatibility we need to provide for our
> core APIs (under the core/ folder).
Regarding compatibility, 'officially' at the moment we have:
a) custom functions
b) soap api
>From 1.2.x onwards, we will add support for plugins.
Unofficially, i'm sure some people have re-themed or changed mantis
internally for their own use - with patchsets that have not (or can/will
not make it into core). With regards to these, and the level of changes
that seem to be going on, it would seem that these patches are going to
need work in 1.2.x+ anyway - im my view, the only hope is that the planned
plugin functionality, and even custom field changes that daryn/myself have
been discussing on/off for months and daily more recently on IRC (aka
support for custom fields to other things then bugs, and more flexibility
in the admin GUI) would allow someone to migrate their changes to a 1.2.x
release in a way that would be supported longterm.
I've not looked at the implementation of the SOAP API (or even usage
statistics of ), but my feeling is this is one level that we:
a) should have a test framework for (if possible)
b) should ensure is supported between releases in some way (or at least
supported as much as possible, with documentation available on breaking
changes).
In terms of custom functions, even in 1.2.x, some of these probably should
be re-thought -
a) custom_function_default_auth_can_change_password --> Both John,myself
and nt_ on IRC have had some discussion of authentication plugin support -
I know NT_ had started a spec on wiki, and that john had started an
implementation as part of his plugin API's, and i've done some tidying up
of the authentication logic to try to move the logic just into
auth_Api.php rather then the login pages themselves. If we allow some form
of plug-able authentication then this custom_function should probably be
removed in favour of that
b) custom_function_default_get_columns_to_view /
custom_function_default_print_column_title --> If those do what I think
they probably do, this feels like something that should be customisable
within the User interface (maybe on a per-user basis). I'm assuming they
control columns displayed on the view issues pages.
So in summary - I think what i'm saying is...
At the moment it's looking like we're trying to improve a lot of areas for
1.2.x:
a) rewritten database_api (backwards breaking api change if we drop some
of the old db_query functionality - db_query/db_prepare_string etc won't
be called anywhere within core code by release.
b) Change to PHP5
c) Possible Change to different mail engine (e.g. swiftmailer/Zend), maybe
support for templated emails.
d) plugins
e) custom fields
etc etc
This leads me to three points:
a) maybe this warrants a 2.0 release over a 1.2.x release?
b) *now* would be a good time to break some API functions if we need to
for the future, and also use this as an opportunity to add some PHPDoc
type documentation to the various API's
c) Whilst we're looking at the above, allowing some of the more 'fixed'
functionality to be customised - either via plugins/ custom_functions or
the User Interface could be nice to ensure that plugin's are sensibly
focused.
> I would also suggest that the guidelines for developing plugins should
> be that plugins developed against Mantis 1.2.x should not claim
> support for Mantis 1.3.x and above. When Mantis 1.3.x is released,
> then the plugin author can be re-release it after testing, or users
> may decide to up such compatibility and do the testing themselves.
+1
Paul
|
