The idea is that something like ad_form would be fleshed out in the forums, and then a proposal would be TIPped and approved.
Also, I'm renaming this thread to a slightly broader topic, and adding some IRC notes.
- Bug fixes should be tested and committed on the current release branch.
- The current release branch is merged back to HEAD after each dot release.
- All commits should
- Code should not be reformatted unless it is being changed functionally, e.eg. unless when you change control flow and reindent to reflect it.
- Database upgrade scripts should only span one release. E.g., a single script should only take a system from 2.0.0 to 2.0.1, not to 2.1.2. This also applies to development milestones - an upgrade script for 2.0.0d1 can only upgrade to 2.0.0d2 (dev 1 to dev 2). It is not necessary to have every development milestone - a script can do directly from d1 to a1 or b1.
- Database upgrade scripts should never go to the release version, because then if a problem is found in a release candidate it cannot be addressed with another upgrade script. E.g., the last planned upgrade script for a package previously in dev 1 would be upgrade-2.0.0d1-2.0.0b1.sql, not upgrade-2.0.0d1-2.0.0.sql. We would rather use rc1 than b1, but this isn't supported yet.
- CVS commit messages should be intelligible in the context of Changelogs. They should not refer to the files or versions.
- CVS commit messages, and code comments, should refer to bug #, tip #, or patch # if appropriate.
- The previous guidelines about API changes apply only to public API. Private API can be changed without TIP.
