We had a BOF during GUADEC to address the extensions breakage that we have every cycle.
The consensus is that we would work on two things: 1) Document a public api that we know will not be subject to a lot of changes. We aren't providing guarantees, but merely that using these api that it is going to be unlikely that it will break. We want to document it so that extension writers will use them, if they go off into the weeds then there is a chance of breakage. At least though it will be their decision. 2) We want to start getting people to start testing extensions prior to the final release. GNOME itself is being blamed for the breakage, and that might be reasonable if there is some flux. However, some extensions break because the version has not been updated (sri raises his hand as a guilty party) The current proposal for 2) is to have a extension testing day where we get people to test extensions based on a 3.17.9? image. We will test extensions with both version checking and without version checking. If an extension works without version checking then, likely we can just update the json file directly. If it fails without version checking then we should file bugs against the extension if possible or put out a errata on the mailing list. The responsibility then lies on the extension writer to update their code to work with the release. Hopefully, we can catch 90% of broken extensions. I'd like start moving forward towards the end of next week and organizing a day for this testing. Now, it would be nice if we can figure out if each extension has a pointer to a git repository and bug tracker though. I don't know if we have something like that. If there are any extensions writer on the list, I would like to hear your thoughts on this. sri
_______________________________________________ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
