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
