As we are finessing our way to Keel-2.0, it is important that we watch our changes to CVS. I would like to propose the following, which in essence, is an online peer review of the changes:
- Before making any changes to CVS, propose the changes first to this mailing list with a summary of the changes, and potential impact to existing users.
- To maintain compatibility, make sure core interfaces in keel-core aren't altered unless absolutely necessary. If needed, make sure we discuss first on list to exhaust other possibilities.
- Each contributor must have all Keel modules checked out, and check that we do not break compiles in any module at all with our checkins. The discussions above are important, because users are likely to have implementations based on core-interfaces, and we will not be able to test we didn't break something. When in doubt, don't change interfaces.
- Before checkins, make sure to run build-tests.sh and make sure our compile, unit and functional tests all pass. Note that our tests don't cover everything yet, so we'll need to be careful even beyond the tests. But if even our meager tests fail, then...well....
- In all changes, try very, very hard to maintain backwards compatibility. If necessary, deprecate the backwards-compatible function, and remove after one major release.
- Changes to Keel should be "generic" in nature, avoid changes specific to a particular environment, container, browser, etc., or, your own local setup.
Please provide some feedback on my comments here. Based on community feedback, I'll modify and once we have something, we'll put up on a new "developer" page I want to put up. Among other things, the developer page will contain the Keel charter, coding guidelines, these CVS guidelines, branching guidelines, etc. Any suggestions on what else to put there are most welcome.
Thanks, Shash
http://keelframework.org/documentation Keelgroup mailing list [EMAIL PROTECTED] http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com
