Backwards incompatible changes in plugin API

[Andriamanitra]

Backwards incompatible changes in plugin API

[JoeKar]

At least from my perspective (which doesn't need to be common) fully reverting it isn't what we want in the first place, since the intention was and is to provide a more abstracted API were we don't need to care about some specific micro internals take place in parallel.
But I give you fully right, that breaking APIs with no changing period isn't the best practice.

So my suggestion would be the reintroduction of these interfaces (partly revert), BUT with our own wrapper function where we can directly expose a deprecation warning. With this we should be save for the adaptation phase with the master as well as the current release.

Any objections?

[dmaluka]

I suppose you could also check at runtime if the new interface is available:

if type(micro.After) == "function" then
    -- use new API
else
    -- use old API
end

[dmaluka]

I've uploaded PR #3211 reverting 4ffc220. With #3211 your plugin should work as fine as it used to. I mean, as unsafe as it used to. From what I can see, your timer callback doesn't synchronize with the rest of your plugin, or with micro, whatsoever. What if e.g. activeConnections or openFiles changes in the meantime, while your time callback is running? It doesn't look like you update activeConnections in an atomic way, and so on. So I'd suggest to switch to the new (safe) API as soon as possible.