[Uml-devel] branching

[Jens Krüger]

It was only a question, whether it is possible yet.

The other point I suggest is, after creating a release (in the future of 
course) we should create a branch, that contains the released version. The 
development should go in the main trunk, and the branch should only contains 
the bugfixes of the released version. The main trunk should automatically go 
to the next release. (as described in the kmoney2 handbook).

Am Montag, 29. Juli 2002 13:26 schrieb Luis De la Parra:
> > It's too late to make a 1.0.3 branch, there's been many changes since
> > then.  I'm also not sure that there's enough developers to warrent two
> > full time branches.  I'm thinking of making some 1.1 pre-releases when we
> > get admin privilages over the project and a 1.1 release when most of the
> > bugs are gone then branch to allow for new features but only change the
> > 1.1 branch for the bugs that really need it.
> >
> > However that's all open to debate.  The Linux numbering scheme may well
> > be more suitable.
>

I agreed to you. Do you have an idea how we can improve the hunting for the 
inherent bugs? My idea is: stop the introduction of new features at this 
time, find most of the bugs by testing or/and code review, and if we are 
sure, the most bugs are found, release it and put it for downloading on the 
web page. 

Does anybody now, whether the bugtracking works at SF, especially for UML 
Modeller? If yes, we should use it.

> I also think it's too late for branch on 1.0.3, so I would suggest
> concentrating all devel. efforts to hunt bugs down on the current cvs code
> for a while, and then maybe create a branch 1.1 (from the current cvs at
> that time) where only bug fixes are allowed, and new features may be added
> to the main branch. having two branches requires more admin effort, but it
> may be a good idea to stabilize the 1.1 version while still allowing new
> features in the main branch. the problem is that bugs should then be fixed
> in the two branches.
>

The only difference is, the user get more releases in the odd numbers, but 
these may a little bit more instable than the even releases. He has to know 
this. 

> I dont really think we *need* the linux numbering scheme since the project
> is not that big, but if you want to have it like that it's ok. don't see
> much difference in having a 1.1 or a 1.2 number on the splash screen as
> long as the code that is released as a offical version (either 1.1 or 1.2)
> is stable.
>
> luis.

-- 

Jens Krüger

Technische Universität München
ZWE FRM-II
Lichtenberg-Str. 1
D-85747 Garching

Tel: + 49 89 289 14 716
Fax: + 49 89 289 14 666
mailto:jens_krueger at frm2.tu-muenchen.de
http://www.frm2.tu-muenchen.de