gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-devel] Re: Understanding code maintenance


From: Karsten Hilbert
Subject: [Gnumed-devel] Re: Understanding code maintenance
Date: Sat, 02 Feb 2008 01:19:23 +0100

Jim wrote:

> I would enjoy a bit of orientation to versioning and what is involved  
> when people contribute code.. "where it goes" etc. If this is too  
> basic to be of interest to the list, do not post there, but if you  
> think you would explain anything that is a choice or preference on  
> your part, and therefore worth others' knowing, feel free to reply  
> there.
Basically, it's all just "my" choice or devel habit.

> Independent of that, I can transfer some of the info on to the wiki  
> if it would help any others.
Sounds good.

> - when anyone has code they would contribute, can they put ("write")  
> it nowhere until they have registered in the savannah cvs
correct

> and does such registration require that a project manager somehow authorizes?
By being authorized as a project member people automatically gain write access 
to the CVS (which is rather unfortunate but it's the way it is).

> - how are multiple branches managed, for example, before the release  
> of 0.2.8.3 there was 0.2.8.1, and then I started reporting things  
> that you began to fix, but you have also added some other things. and  
> you are at the same time committing things that will not be available  
> until 0.2.9. So when you are doing these things, do you (and would  
> everyone else who would also contribute code) need to decide whether  
> to apply any particular change to one or multiple among
> 
> 0.2.8.1 (supposing people were using it, and it needed patching)
> 0.2.8.2
> 0.2.8.3
> 0.2.9
Surely so.

The branching/tagging strategy is this (assume 0.2.7):

- when ready for a release, tag the CVS head as "rel-0-2-7"
  - this will the root of a branch
  - this branch will only ever receive bug fixes

- create a branch "rel-0-2-7-patches"

- in that branch tag "rel-0-2-7-rc1"
  - release that state as v0.2.7.rc1

- fix bugs and tag in that branch as "rel-0-2-7-0"
  - release v0.2.7.0

- fix bugs and tag in that branch "rel-0-2-7-1"
  - release v0.2.7.1

- etc

IOW, 0.2.7 is the major release with new features.

0.2.7.x is a bug fix release based on 0.2.7.
0.2.7.x will NEVER have new features.
0.2.7.x will NEVER need a database change over 0.2.7.x-1

When fixing bugs I fix them in two places: whatever is the current to-be bugfix 
release, say 0.2.7.4, and in CVS HEAD. IOW, currently we advise people to keep 
up with releases as we don't backpatch. This may need to change at some 
(hopefully much) later time.

Mind you, the fix in the bugfix release may be different from the fix in CVS 
head both conceptually as well as code wise.

Adding features is done in CVS head *only*.

> in other words, is there manual work and a risk of people (not  
> you ;-))
I have made errors before and will make more. I even mistagged CVS trees 
previously ;-)

> making errors, in failing to do things multiple times when  
> more than one branch will need to get the same modification, or do  
> these somehow "roll upward"?
They don't. CVS isn't really well-suited to distributed development. The C 
might stand for Central just as much as for Concurrent :-(

> Do commits into the "main trunk" (or "head" ?) happen at multiple  
> points, even in between official releases and maybe even with just  
> bug fixes?
No. They always happen upwards of the current official release before what will 
become the branch root for the next official release.

> If we are considering the 0.1, 0.2 to be "major releases" and the 8  
> and 9 (in 0.2.8 and 0.2.9) to be "minor releases" and the "3" in  
> 0.2.8.3 is a bug fix,
correct

> I assume we would never see a database schema  
> change with just bug fixes,
correct

> but we could get a schema change with a  
> minor release like at 0.2.9?
correct, and we did with every single one so far

We provide tested conversion scripts for going from schema N to schema N+1.

> Is the schema version-numbered?
Yep, it's at version 9 right now. We even made the version detectable by 
hashing the table layout.

Karsten
-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail




reply via email to

[Prev in Thread] Current Thread [Next in Thread]