Difference between revisions of "Uno/API Deprecation"
From Apache OpenOffice Wiki
< Uno
(New page: = If/How to Deprecate/Change/Remove UNO API = Discussion has been going on for years what to do with known-stale/badly designed/un-used UNO IDL types. Random ideas: * decide on rules whe...) |
(add Time/DateTime) |
||
(3 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
= If/How to Deprecate/Change/Remove UNO API = | = If/How to Deprecate/Change/Remove UNO API = | ||
− | Discussion has been going on for years what to do with known-stale/badly designed/un-used UNO IDL types. | + | Discussion has been going on for years what to do with known-stale/badly designed/un-used UNO IDL types. Here's an attempt to collect some ideas. |
Random ideas: | Random ideas: | ||
− | * decide on rules when published types may be removed or changed | + | * decide on rules when published types may be removed or changed: |
** number of clients in OOo | ** number of clients in OOo | ||
− | ** (estimated) use outside OOo project (i.e. people that don't read interface- | + | ** (estimated) use outside OOo project (i.e. people that don't read interface-announce) |
** how "bad" is the API - i.e. if everybody agrees it plainly sucks, remove anyway despite points above | ** how "bad" is the API - i.e. if everybody agrees it plainly sucks, remove anyway despite points above | ||
* deprecate in one feature release (add a suitable warning mechanism when using such API) | * deprecate in one feature release (add a suitable warning mechanism when using such API) | ||
* remove in the following feature release | * remove in the following feature release | ||
− | * limit impact considerations | + | * limit impact considerations to non-ABI-dependent UNO bindings (i.e. the assumption is that c++ components break randomly anyway for every other release, so they shouldn't block API changes) |
+ | |||
+ | == Kill file == | ||
+ | |||
+ | List of problematic API that should be considered for deprecation/change/removal: | ||
+ | * css::document::XDocumentInfo [[User:mst]] | ||
+ | * css::beans::StringPair - there's the generic beans::Pair<> type now [[User:thorsten]] | ||
+ | [[Category:Uno]] | ||
+ | * css::util::Time and DateTime lack a timezone field. Just adding that would be less work than defining new structs. [[User:mst]] |
Latest revision as of 14:22, 12 October 2010
If/How to Deprecate/Change/Remove UNO API
Discussion has been going on for years what to do with known-stale/badly designed/un-used UNO IDL types. Here's an attempt to collect some ideas.
Random ideas:
- decide on rules when published types may be removed or changed:
- number of clients in OOo
- (estimated) use outside OOo project (i.e. people that don't read interface-announce)
- how "bad" is the API - i.e. if everybody agrees it plainly sucks, remove anyway despite points above
- deprecate in one feature release (add a suitable warning mechanism when using such API)
- remove in the following feature release
- limit impact considerations to non-ABI-dependent UNO bindings (i.e. the assumption is that c++ components break randomly anyway for every other release, so they shouldn't block API changes)
Kill file
List of problematic API that should be considered for deprecation/change/removal:
- css::document::XDocumentInfo User:mst
- css::beans::StringPair - there's the generic beans::Pair<> type now User:thorsten
- css::util::Time and DateTime lack a timezone field. Just adding that would be less work than defining new structs. User:mst