Manifest -
require Dev eMail
Send eMail out Deprec notices to the Dev/Authors not Sire Owner/s
Apache error_log for Site owners
Dat wud work for me...
anyone else ?

@iionly @cash @DDS @Steve

Thanks for your answers!

Anyways, I agree with iionly. I've seem tons of 1.8 plugins being released every week, and it would be bad if they weren't compatible with 1.9

 Plugins written for Elgg 1.8 *should* just work on Elgg 1.9.

 I hope so. I mean, it is bad enough we don't have an official version of Tidypics for elgg 1.8 and then 1.9 comes along and none of them work. 

Elgg 1.8 introduced a new framework for HTML/CSS. Rewriting the UI code is time consuming.

Will 1.9 experience such rewriting at any point that will require to do changes to themes?

We've found that if we don't make the warnings annoying, plugin authors don't update their plugins.

Loving that =D 

We are not making any large changes to the html/css in Elgg 1.9. There may be bug fixes and a few enhancements. I haven't looked at the tickets assigned to 1.9 in a while so I don't remember. My guess is that the themes will need to update for the changes to comments - but that will only be one or two views.

Cool. So Tidypics for elgg 1.9 is really far far away?

Tidypics for elgg 1.9 should not be any father away than Tidypics for 1.8.

very nice and interesting information but i have one question

In elgg 1.9 the layout ( Html and Css ) font end will be same as elgg 1.8 or it will be different, something new?

The default layout will be the same.

thanks very much.

I would advice to send notices about deprecated functions only in case functions were changed two iterations back. In case I'm running 1.7 and upgrading to 1.8, I shouldn't bother about methods which were renamed in 1.8 in case old ones still work. I should have time to upgrade them. In case I upgrade from 1.8 to 1.9, then it would be ok to show strict notifications about not upgraded methods from 1.7. Otherwise, most Elgg users will just think plugins created with deprecated functions won't work for them, which is not always true. Then, at 1.10 those methods from 1.7 could be removed completely.

Scanning plugins for deprecated functions at upload is an interesting idea. It would surely help to notify the developer about possible issues, maybe not only telling about deprecated functions being used but also include some detailed information where they are (file / line number). I would tend to include all warnings when informing the developer: if a plugin states to be aimed for Elgg 1.X then there's no need to keep any functions within the code already deprecated in Elgg 1.(X-1). Also, the functions deprecated within the current Elgg version should be listed: "should have time for upgrade" vs. putting some pressure on the developer... I tend on putting on some pressure. Otherwise, the fixes might not been done before the next major Elgg version is released. In theory, the developers would have been able to upgrade their plugins while Elgg 1.8 was in beta testing phase to release them just in time with the final release of Elgg 1.8. Obviously, this did not happen.

Showing the stats about possible issues with deprecated functions is surely different from informing the developer. The stats could have two categories: minor issues and major issues. Minor issues would be sort of "plugin should work without any major issues" while major issues would state "most likely this plugin will not work with this version of Elgg. Please test thoroughly before using on productive site". Still, I would not hide any issues from the people downloading the plugins: "Quality first!"

P.S.: I posted my concerns about appending the compatible version information to the plugin title already elsewhere. When scanning the plugin code for possible issues it seems natural to include the compatible version together with the stats about issues - maybe next to the plugin download button... When showing the number of possible issues (if there are any) and still appending the version number to the plugin name this seems kind of inconsequential to me. Somehow, the appended version number could be seen as kind of a quality proof ("tested by the Elgg development team and proofed to work in Elgg 1.X"). When further down on the same page it would show "XX major issues - will break your site!" this would be rather strange. Again my suggestion: let the developer decide on the plugin name himself. When showing the compatible version information elsewhere on the plugin page it could be made visible that this information was only provided by the uploader and was not proofed by anyone else directly.