I took some time to read over the chapter in the CVS manual on branching and merging. I have some comments now on the method I think we should use for the development branch in the OpenJUMP CVS.
I believe that we should use the method described in Michael's option #3 in this thread. This is basically two branches in the CVS, one stable and one unstable. Developers can work on and test changes and new features in the development branch. When changes or new features have been completed in the unstable branch they can be merged into the stable branch, as long as they don't break the nightly build. (The nightly build will continue to be built from the stable branch.) Sascha wrote: "I would vote for short merging intervals (1 month or so). Such a merge brings the current release to a new second digit after the stable version number (1.2 -> 1.2.1). If we think its time for new major release we can increment the first after dot (1.2 -> 1.3). Having the devel and the stable branch coupled so tightly helps us to fix urgent bugs in time and develop new features." I don't know how well this will work for our group of developers. I may be mistaken, but under this type of system I believe all changes or new features in the unstable branch would have to be working in a month of less after they are commited, because they will be going into the stable branch at 1 month intervals. I can forsee a situation under this sytem where we are always holding back a merge of the stable and unstable branches because one or more developers (probably me) doesn't have his stuff "working" and ready to commit. Then the other developers are upset because they have to wait for their changes to get into the stable brach via the merge. I would suggest this system as a possible alternative: Each developer and/or development team would be responsible for moving its changes and new features from the unstable branch to the stable branch. (I believe we could accomplish this by using some good file structure organization.) If the different developers can coordinate a "universal merge" from the unstable branch to the stable branch that's great, but under this system it wouldn't be forced. Every six months we will shoot for a new release of the stable branch. At this point we can update the version number of the unstable branch. Here is an example: Let's say the that we create the unstable branch of OpenJUMP today. The current revision number of the OpenJUMP CVS is 1.3. Based on what I read in the CVS manual I think our unstable branch would receive a revision number of 1.3.2. At the end of the year we make a new stable release of OpenJUMP and update the revision number of OpenJUMP to 1.4. At this point we would also update the revision number of the unstable branch to 1.4.2. Under this system there would be 3 versions of OpenJUMP available at any one point in time: [1] The latest stable release. (An annual or biannual snapshot of the stable branch of the OpenJUMP CVS.) [2] The nightly build of the stable branch in the OpenJUMP CVS. [3] The development builds created by different development teams from the unstable branch of the OpenJUMP CVS. I'd say a month before a planned stable release we would freeze all merging of changes and new features from the unstable branch into the stable branch. Let me know what you guys think of the basic system that I have outline. If there are no major objections I can work on making the needed changes to the CVS this week. The Sunburned Surveyor On 6/3/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > Thanks for all of the suggestions about how we can manage a > development branch in the OpenJUMP CVS. I have downloaded the CVS > manual and the CVS book this morning. Please give me a few days to > read about branching and merging and then I will try to add something > intelligent to this conversation. > > Hopefully we can then make a decision about how to implement a > development branch, while preserving our nightly build. > > The Sunburned Surveyor > > On 6/3/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote: > > I would prefer the following: > > > > 1 month n-month (n+1)-month > > --\---- devel-----\----...---\--------------\-----....----\--> > > \ \ \ \ \ > > release 1.2 --------....---\ \ \ > > \ \ \ > > release 1.3--------------------> > > > > Have one current stable and one devel branch. No support > > for older versions. You can do this if you have enough man > > power. Which we don't have at the moment. > > I would vote for short merging intervals (1 month or so). > > Such a merge brings the current release to a new second digit > > after the stable version number (1.2 -> 1.2.1). If we think > > its time for new major release we can increment the first > > after dot (1.2 -> 1.3). Having the devel and the stable > > branch coupled so tightly helps us to fix urgent bugs in time > > and develop new features. But the development/release model > > should not be set in stone. It depends on the man power > > (which hopefully will increase). All it have to be is > > that has to be transparent to the users. > > > > - Sascha > > > > > > Michaël Michaud schrieb: > > > Hi, > > > I can see several ways to manage stable/development versions (mainly > > > depending on how much effort we can put in maintaining all the stuff - > > > not much until now). > > > Hope my ascii art will be readable > > > > > > 1 - The most simple (CVS must be always clean and releases are > > > done after a period where every developper concentrate on tests and bug > > > fixes) > > > -----------------------------------------------> Development version (CVS) > > > \ \ > > > release 1.2 release 1.3 > > > > > > > > > 2 - Stable versions are derived from development CVS as needed > > > (bugs fixes are done on both branches during some weeeks, but the > > > development > > > branche is ging on without threatening the stable one) > > > -----------------------------------------------> Development version (CVS) > > > \ \ > > > ----------->1.2 ------------>1.3 Bug fixing > > > > > > 3 - Two branches > > > (needs to take new developments of the development branch, to > > > backport them and to test them in the stable branch) > > > -----------------------------------------------> Development version > > > \ \ \ > > > \ \ \ > > > Syncronization work > > > -----------------------------------------------> Stable branch > > > > > > It seems to me that we have not enough development resource to do more > > > than [2], but I'm not a professional developper, and I may ignore how we > > > can organize ourself to have a stable branch and a development branch > > > without loosing too much energy. > > > > > > My two cents > > > > > > Michaël > > > > > > > > > Stefan Steiniger a écrit : > > > > > >> Hei, > > >> > > >> hope it is ok to send a copy on the list. > > >> > > >> I am not sure about it, since it doubles efforts in copying and > > >> syncronizing the sources and i think nightly builts have to be somehow > > >> stable (i.e. are runnable) > > >> > > >> What would be possible is to make a new tree from the current module > > >> that contains the "stable" version. While the current cvs versions stays > > >> would be the instable one. > > >> > > >> Because i would not like to loose the nightly built. This would ensure > > >> that changes made are still one day afterwards avaliable to users. > > >> > > >> other oppinions? > > >> > > >> sorry if i missed some of the emails that dicussed that issue - simply > > >> to much are coming in at the time. > > >> > > >> stefan > > >> > > >> Sunburned Surveyor schrieb: > > >> > > >> > > >>> Stefan, > > >>> > > >>> It sounds like a couple of the developers would like to have an > > >>> unstable branch of the OpenJUMP code base that they could work in. > > >>> Would you have a problem hosting this in the OpenJUMP CVS? > > >>> > > >>> If you have reasons to avoid this I will create a copy of the OpenJUMP > > >>> code at the SurveyOS that can be used instead, but I think it would be > > >>> easier to keep the two branches in the same repository. > > >>> > > >>> Let me know what you prefer. I can let the list know about our > > >>> decision and make the changes needed. > > >>> > > >>> Thanks, > > >>> > > >>> Landon > > >>> > > >>> > > >>> > > >>> > > >> ------------------------------------------------------------------------- > > >> This SF.net email is sponsored by DB2 Express > > >> Download DB2 Express C - the FREE version of DB2 express and take > > >> control of your XML. No limits. Just data. Click to get it now. > > >> http://sourceforge.net/powerbar/db2/ > > >> _______________________________________________ > > >> Jump-pilot-devel mailing list > > >> Jump-pilot-devel@lists.sourceforge.net > > >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > >> > > >> > > >> > > >> > > > > > > > > > ------------------------------------------------------------------------- > > > This SF.net email is sponsored by DB2 Express > > > Download DB2 Express C - the FREE version of DB2 express and take > > > control of your XML. No limits. Just data. Click to get it now. > > > http://sourceforge.net/powerbar/db2/ > > > _______________________________________________ > > > Jump-pilot-devel mailing list > > > Jump-pilot-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > Jump-pilot-devel mailing list > > Jump-pilot-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
