On 24.10.21 20:57, Jörg Schmidt wrote:
-----Original Message-----
From: Peter Kovacs [mailto:pe...@apache.org]
Sent: Sunday, October 24, 2021 2:19 PM
To: dev@openoffice.apache.org
Subject: Re: API doc on web site [Was: Accessing the comment
object (annotation) in Draw/Impress via API]
Hi Jörg,
Check:
Version Number Assignment (Apache OpenOffice internal)
Structure
<major>.<minor>.<micro>
Explanation
<major>: huge release with visible changes and new features including
incompatible API changes if necessary. Translation updates are most
often necessary to address the UI visible changes.
<minor>: smaller improvements of features that don't need any
translation. And of course any kind of bug fixes.
<micro>: only selected bug fixes and most often only critical
ones. This
includes any potential security issues.
From: https://cwiki.apache.org/confluence/display/OOOUSERS/Releases
Yes, agreed.
That is the current policy. So well as long as compatible we could
Change the API with a minor Release.
I see no need and no justification for watering down clear rules/explanations.
The question of what "compatible" actually means is by no means easy to answer.
Example: Perhaps there is a property, method, etc. in the API that accidentally has a spelling mistake in its name (I recently had something like this in LO regarding a parameter of a Posgresql access) - on the one hand, one can then argue that a name correction that does not change the actual function would be compatible, but one can also argue that it is incompatible because only the old naming (which is possibly already used a lot in projects) no longer works.
I define Incompatible on User API level if the API user has to change
his work, as a result of changes in a release.
--
This is the Way! http://www.apache.org/theapacheway/index.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
