> -----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. greetings, Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
