Tres Seaver wrote:
Jim Fulton wrote:
3. Up to this point, we haven't had to be careful about managing bugfixes across multiple releases.
Sure we have. We've had a release branch for some time. Perhaps I should add:
The complaint you made earlier today (about bugs fixed on the head, but not on the release branch) is a symptom of this issue. FWIW, it is standard doctrine that bugs should be fixed *first* on the release branch, and then forward-ported to the trunk, rather than vice versa.
I agree that that is a good doctrine.
...
When collaborating on a feature which touches many files, it is often desirable to check in intermediate versions; activity branches make this possible, without risking the stability of the trunk.
Yup. There are definately examples of this in Zope 3's history and future. I'd put it a little differently, in that it is not necessarily the number of files but the overall time to complete a development project that sometimes makes separate development (activity) branches necessary.
> The CVS
document (http://dev.zope.org/CVS/ZopeCVSFAQ) says:
It is very important that the trunk remain stable so that releases can be made on short notice. To keep the trunk from becoming unstable, all work is done on branches in CVS and when the work has stabilized it can be merged into the trunk.
For Zope 3 and svn, I would change this to something like:
It is very important that the trunk remain stable so that releases can be made on short notice. To keep the trunk from becoming unstable, no change can be checked into the trunk, or to a release branch unless:
- All tests pass, and
- All new code has adequate unit and functional tests.
If you need to check in intermediate work, because a project takes a long time or there are multiple participants, then create a development branch and work there. When development is completed and the resulting changes are stable and adequately tested, then the branch can be merged to the trunk (or to a release branch) and committed if all tests pass.
OK, that sounds fine. Another reason for an activity branch: the work is "experimental", and may never be merged; putting on a branch lets others evaluate it without risking stability.
Tres.
--
===============================================================
Tres Seaver [EMAIL PROTECTED]
Zope Corporation "Zope Dealers" http://www.zope.com
_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
