Guys, First off: this is a very good idea.
For what it's worth, I'd like to offer some ideas on this. If you go ahead and write this document, why not take it a bit further and make things more explicit: > > Continuing to support older releases State how long support for older releases will be available. It sounds reasonable if all 2.1.X releases are supported, but only the last of 2.0.X and of 1.X. This doesn't of course prevent anyone from giving support on other releases. ;-) > > Maintaining a change log to help with upgrades As mentioned before: add scripts/XSL/instructions to help with the change. > > Strongly avoiding breaking interfaces > > Conducting open, public discussion of design and development > > Querying userbase to determine impact of potential changes > > Responding to the userbase, even reverting changes when necessary > > Voting on major additions, changes, deprecations, and removals > > Deprecating interfaces instead of immediately dropping support e.g. state how long deprecated code will be around before it is actually removed (e.g. X releases later). I suppose this will also avoid several "vote" threads. > > Only allowing code that has a community to support it If new things are added (e.g. workflow), they always start as a scratchpad block with "scratchpad" actually in the package name. Once they reach maturity to earn their own block they are moved to a regular block outside the scratchpad. Now I see lots of blocks marked as "scratchpad" in the build, but hardly any of them are actually in src/blocks/scratchpad. Is it possible to move deprecated code to a src/**/deprecated without changing the package names? In this case it is also more clearly which code is deprecated. Yes, I know: all this requires more work, but I think it makes the "contract" more clearly. Bye, Helma
