Forum OpenACS Q&A: RFC: CVS commit guidelines (was 'Guidelines for what should and should not be TIPped')
- It changes the core data model
- It will change the behavior of any core package in a way that affects existing code.
- It is a non-backwards-compatible change to any core or standard package. We don't have a firm list of standard packages so I propose for now that any package in dotlrn-prereq is a standard package.
- it adds a new function to a core package in a way that
- does not change any existing API functions
- does not change the data model
- has no negative impact on performance
- OR it is a change to a non-standard package
A proposed change need not be TIPped IF
Ie, adding a new API wouldn't require a TIP, and even changing an existing API function wouldn't require a TIP if the new behavior only occured if a flag were selected, and the flag is optional and off by default.
The place where these rules fall down is ad_form, which wouldn't require a TIP by these rules but clearly would have benefitted from group review of the syntax and names before it was implemented or modified.
We are about to commit notifications in FAQs, and then in other packages, I think those not need a TIP...
- 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.