When LibreOffice developers do adjustments to the UNO API (which is done carefully) they will mark the commit with the words "API CHANGE" so it can be marked in the release notes. Here are some examples: http://cgit.freedesktop.org/libreoffice/core/log/?qt=grep&q=API+CHANGE It would be nice to create a git hook that triggers on these commits and sends a mail to the libreoffice user list at users@global.libreoffice.org: - showing the body of the commit message - a link to the commit for reference - and kindly asking user to test if their extensions and scripts still work with the changes made by running a daily build from http://dev-builds.libreoffice.org/daily/ or alpha/beta releases of upcoming major versions. The earlier a change gets notified, the easier it is to fix regressions or for extensions: to update to the extension to for the new major release on time. As a sideeffect this might give us more coverage and testing of daily builds, which hardly is a bad thing.
AFAIK current git hooks can be found at: http://cgit.freedesktop.org/libreoffice/contrib/dev-tools/tree/git-hooks/core.git/hooks/update
We also have the other option of integrating it into out other notifying scripts. We already have a number of scripts running for each commit. Adding one more is easy. They can be found at http://cgit.freedesktop.org/libreoffice/contrib/dev-tools/tree/ciabot The new script would need to be plugged into run-libreoffice-ciabot.pl:79
Hi, In general a big plus, but .. > It would be nice to create a git hook that triggers on these commits and > sends a mail to the libreoffice user list at users@global.libreoffice.org: > [...] could this lead to a flood of mails with API changes to the users list, I mean more then a few a day? I doubt if that is OK.
@Cor: No, see the link: http://cgit.freedesktop.org/libreoffice/core/log/?qt=grep&q=API+CHANGE shows its far less: around 2 per week on average, although some will come in bursts of 3-4 ....
FWIW, an alternative would be to have the notification in regular intervalls (e.g. two weeks) and than collect what API changes have been done since the last notification (a bit like the gerrit digest mailer with a longer intervall). But TBH, I would like to leave the details to the implementer ...
(In reply to comment #4) > shows its far less: around 2 per week on average, although some will come in > bursts of 3-4 .... Fine. Incidental 'bursts' of that size won't be a problem of course.
Please bear in mind it isn't just fairly technical developers of 'extensions' that can be affected. End-users with application developments of their own can also be affected. The details of many of the commit messages are incomprehensible to such as myself. However, I well understand that changing a data type in a form control could affect my code. I do understand it's difficult to please everyone, but I'm just trying to clarify some of the characteristics of your potential audience.
(In reply to comment #7) > Please bear in mind it isn't just fairly technical developers of > 'extensions' that can be affected. End-users with application developments > of their own can also be affected. > > The details of many of the commit messages are incomprehensible to such as > myself. However, I well understand that changing a data type in a form > control could affect my code. The Good Thing is: You dont need to completely understand the commit message to test a daily build. Actually its a Good Thing if the tester isnt _too_ confident in "completely understanding" the commit message, as it can lead to the reader thinking: "ah, this cant possibly break my stuff, so Im not testing ..." (see also: http://www.youtube.com/watch?v=4XpnKHJAok8&feature=player_detailpage#t=1399s ). This is not what we want for three reasons: - if the reader tests the change, he/she is not only testing the specific scenario, but also other stuff - if the reader is confident in understanding the message, but misunderstands, there is less testing, which is not what we want - the the reader is confident and understands the message right, the message might still be wrong or incomplete. Again, testing would help the case here.
Migrating Whiteboard tags to Keywords: (EasyHack DifficultyBeginner SkillScript) [NinjaEdit]
JanI is default CC for Easy Hacks (Add Jan; remove LibreOffice Dev List from CC) [NinjaEdit]