[Top][All Lists]
[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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Gnumed-devel] Re: Understanding code maintenance,
Karsten Hilbert <=