Here's a quick picture of how we might use CVS branches to manage our upcoming development. An explanation follows. +--MARC-+ / \ / \ -main line--+-----+-----+-------------+-+--------------+-> development \ \ / \ / \ \ / +-rel_1_4-++---> 1.4 branch \ \ / / \ +-rel_1_2-+-+---------------+------> 1.2 branch \ / \ / +---NT----+ (This picture is a gross over-simplification.) The main line is where all normal development should happen (e.g., seperation of presentation and logic and addition of http::template). Sometimes it makes sense to create a branch. This could be to stabilize a release (e.g., re_1_2 and rel_1_4) or to integrate big changes that have happened outside the tree (e.g., MARC or NT). Branches represent temporary copies of the tree, and can be operated on (cvs add, remove, commit, checkout, update, etc) without affecting the main line. Any time we create a branch, we should plan on merging (or backporting) changes back to the main line (and perhaps to other branches as well). In the example above, we already have a rel_1_2 branch. We should create an NT and a MARC branch to hold the changes for these two development efforts. As the NT tree is solidified, we can backport it into the rel_1_2 tree and from there into the main line. Once the code has been backported, we can close this branch down. As the MARC tree solidifies, we can merge it directly back into the main line preparatory to creating the rel_1_4 branch. Again, once backported, this branch can be closed. The rel_1_2 tree should never be closed down. It will represent the ongoing work on the 1.2 stable releases. We will want to merge changes from this branch into the main line on a regular basis. Once the rel_1_4 branch is created, we can backport rel_1_2 changes into that branch as desired. After the rel_1_4 branch has been created, we will want to merge stabilization changes back into the main line from it on a regular basis. For hints on the technical bits involved in using CVS and branches, please look at http://cvsbook.red-bean.com/cvsbook.html (or, even better, buy a copy of the book).
Pat Eyler wrote:
Here's a quick picture of how we might use CVS branches to manage our upcoming development. An explanation follows.
+--MARC-+ / \ / \ -main line--+-----+-----+-------------+-+--------------+-> development \ \ / \ / \ \ / +-rel_1_4-++---> 1.4 branch \ \ / / \ +-rel_1_2-+-+---------------+------> 1.2 branch \ / \ / +---NT----+
I strongly agree with this schema, and am very impressed (great ASCII art ;-)) About version naming : if I understood our iirc, we will use the linux method (1.2 : stable release, 1.3 : unstable release) An other remark : the next stable version will be 1.1.2, from 1.2 branch. How (chris ?) do we solve this ? We should rename 1.2 branch 1.2.2 (as it's stable version), and maybe have a 1.1.3 release at anytime (with partial NT port or partial MARC support for example). Last question : how do we build a version from branch ? Lot of questions I think, but it's quite unclear in my mind... -- Paul
On Fri, 10 May 2002, paul POULAIN wrote:
Pat Eyler wrote:
Here's a quick picture of how we might use CVS branches to manage our upcoming development. An explanation follows.
+--MARC-+ / \ / \ -main line--+-----+-----+-------------+-+--------------+-> development \ \ / \ / \ \ / +-rel_1_4-++---> 1.4 branch \ \ / / \ +-rel_1_2-+-+---------------+------> 1.2 branch \ / \ / +---NT----+
I strongly agree with this schema, and am very impressed (great ASCII art ;-))
emacs is great isn't it?
About version naming : if I understood our iirc, we will use the linux method (1.2 : stable release, 1.3 : unstable release)
Good point, 1.1 releases would be spun out of the rel_1_2 branch and 1.3 releases would be spun out of the rel_1_4 branch. Sorry I wasn't clear about this.
An other remark : the next stable version will be 1.1.2, from 1.2 branch. How (chris ?) do we solve this ? We should rename 1.2 branch 1.2.2 (as it's stable version), and maybe have a 1.1.3 release at anytime (with partial NT port or partial MARC support for example).
My cut is that the next release should be 1.2.0 (just stabilization and simple katipo mods). If we can integrate the NT support, we should do that in the 1.2.X series and backport it from the rel_1_2 tree into the main line for ongoing support. If people feel strongly, we could call the first 1.2 release 1.2.2. Once 1.2 is out and we're comfortable with it, we can start the rel_1_4 tree with MARC support and templates. Shortly after we create the branch, we should release 1.3.0
Last question : how do we build a version from branch ?
A version is, to me, just a tarball of a given branch at a given point. It probably needs a bit of cleaning (get rid of CVS specific stuff and the like), but the work could be scripted.
Lot of questions I think, but it's quite unclear in my mind...
No problem. Please keep asking questions until it is clear in everyone's mind. -pate
-- Paul
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net _______________________________________________ Koha-devel mailing list Koha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/koha-devel
On Fri, 10 May 2002, paul POULAIN wrote:
Pat Eyler wrote:
A version is, to me, just a tarball of a given branch at a given point. It probably needs a bit of cleaning (get rid of CVS specific stuff and the like), but the work could be scripted
That's what I thought. So, we should rename branches don't we ? It would be HIGHLY more comprehensive...
Do you mean having a rel_1_3 tree? That could work, but since the 1.3 stuff just becomes 1.4 when the release manager waves her wand over it it seems like a needless step. (If I'm wrong, please let me know.) -pate
-- Paul
participants (2)
-
Pat Eyler -
paul POULAIN