[Dltk-dev] HEAD unlocked and Maintenance commit policy

[Andrey Platov <andrey@xxxxxxxxx>]

Hi folks,

We're delivered all the DLTK bits to Ganymede, congratulations and thanks to all for the great work on the release!

Please feel free to commit pending changes to HEAD it is unlocked. 

Also I'd be happy to discuss 0.95 Maintenance branch commit policy. First of all it's for service releases (0.95.x). According to Eclipse Versioning policy service release should not contain "externally visible" changes (primarily public API, more info here: http://wiki.eclipse.org/index.php/Version_Numbering). So first rule is just feel free to commit anything, which do not break API.

DLTK's (and not only DLTK's) "problem" is we do not have well-defined public API. There are still many cross-plugin references to *.internal.* packages, so in many cases it's impossbile to identify weither API is "public" or "internal". Of course if we'll consider everything is public - we'll be completely tied and will not be able to do a lot with maintenance stream. 

As an incubating and non-mature project I think we may be a bit flexible with API changes and allow some API breaks, but this should be controlled breakage. So I have following proposal:

1) Please avoid significant API changes (especially within non-internal packages, which are "public" by definition). I will not try to define meaning of "significant" - just please choose a way with mininal impact on API when working on a fix/improvement.
2) Protect community. There are some projects around, which depends on DLTK 0.95, and our main goal with service release to keep them well and running after their users upgrade DLTK to 0.95.x. Since amount of such users and number of such projects is not clear at the moment it's hard to predict impact of some API change: I'm sure we was able to hack 0.9 maintenance as much as we want becuse most of community interest was targeted to 1.0 (0.95). I guess 0.95 time may be different and there are some parties interested in API compatibility and non-breaking upgrades. So I'm proposing to allow dependent project owners to veto on some breaking change. Veto process is simple to post a message to this list with information regarding API change and project, which puts a change under a ban. Until veto received we assume an API change is non-breaking. 
 
Of course this proposal may not work (e.g. there are millions of CDs with some DLTK 0.95-based product already sent out to the shops with "Works with DLTK" logo :), please share your thoughts to fix maintenance policy.

Thank you,
Andrey