Stephan, You wrote: "I am more than happy to watch the process of getting a development trunk in OpenJUMP development."
That is awesome. I don't think that anyone is going to argue with your volunterring. :] You wrote: "The so called trunk is the (current) CVS HEAD which gets branched into release-branches which can be kept separately." I think I am trying to describe the same thing, but not as well.I may have incorrectly referred to a "stable branch" and an "unstable branch" when what we really want is a stable code in the trunk or CVS HEAD and a branch for the unstable code. The Sunburned Surveyor P.S. - Are you a registered developer on SourceForge? You will need to be registered before we will be able to give you admin rights to the CVS repository at the JPP. On 6/4/07, Stephan Holl <[EMAIL PROTECTED]> wrote: > Hello Sunburned, > > I am more than happy to watch the process of getting a development > trunk in OpenJUMP development. As I am no dev (and therefor not able > to voite) but a power-user I would second Saschas proposal of CVS > structure: > > > > > > > > 1 month n-month (n+1)-month > > > > --\---- devel-----\----...---\--------------\-----....----\--> > > > > \ \ \ \ \ > > > > release 1.2 --------....---\ \ \ > > > > \ \ \ > > > > release 1.3--------------------> > > The so called trunk is the (current) CVS HEAD which gets branched into > release-branches which can be kept separately. I am involved in several > OS software development where this structure is quite common. > > To introduce this now would lead into adding a branch (release_1.2) of > the current HEAD. Perhaps it is not so difficult to set up nightly > builds from both HEAD and release-branch? > > Just my 0.02 ¢ > > Stephan > > > "Sunburned Surveyor" <[EMAIL PROTECTED]>, > [20070604-10:34:27]: > > > 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 > > > -- > Stephan Holl <[EMAIL PROTECTED]>, http://intevation.de/~stephan > Tel: +49 (0)541-33 50 8 32 | Intevation GmbH | AG Osnabrück - HR B 18998 > Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner > ------------------------------------------------------------------------- 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
