[Ctk-developers] CTK Update to latest DCMTK

OFFIS DICOM Team dicom at offis.de
Wed Aug 3 10:07:26 EDT 2011


Hi Benoit and everbody,

Am 03.08.2011 15:36, schrieb Benoit Bleuze:
> This discussion is a bit diverging from the the engineering side towards
>  compilation issues.

Hopefully those are mostly solved now so everybody can compile and use CTK
with the current DCMTK. If there are any urgent issues, let me know or open
an issue on github and assign me. IMHO many of problems can be solved once
and will not appear again to soon, since most of them were due to
incompatible/insufficient build settings.
>
> Of course solution 1 requires to take special care that each new commit
> in DCMTK head doesn't break parts that were deemed common to both
> versions at first. That is to me the biggest problem with solution 1. and
> therefore I would discard it.
>
> I can share the experience we have developing Medinria 2.x: we froze to
> 3.6  (in fact some commits after that allowed for shared libraries). We
> are still checking out that specific SHA1. I don't think you guys at
> Offis tag your repos with regular snapshots?

No, so far we do not on git. We offer regular snapshot packages [1] every
1-2 months if we added a special feature, or did another step forward that
we think is worth releasing a new packaged version. Note that a snapshot
does not undergo significantly more testing than a normal checkin.

> At least not since 3.6.0, but do you plan doing so for say intermediate
> versions as Marco suggested? If you don't, then I would stick to 3.6.0
> strictly, now if DCMTK does release intermediate tagged versions, I
> would try to stick to these snapshots, but definitely no dual versions
> except in a specific DCMTK-BleedingEdge branch of CTK.

This is somehow what we do now in CTK -- selecting a specific tag and use
that. I think this is a good way to do it, if there are no snapshot
taggings. We could add those tags (must talk to my colleagues though) but I
doubt that you would win too much.

We could also informally align CTK with the snapshots, i.e. if a snapshot
comes out every 1-2 months, I locally update CTK (if necessary) to that
DCMTK tag, test that on my windows and linux maschines and publish the patch
to you, preferably (:-)) on my own branch on github. Then people can test it
before the new DCMTK snapshot version is taken over into the main branch.
>
> And indeed Marco, Just a tag at several intervals in time would be
> beneficial to CTK itself I reckon. Even you don't "release" anything, a
> tag on a commit that generally compiles well and with no obvious crash in
> core functionalities happening soonish, and then every month or so would
> be a blessing, just to know what we are talking about. Also it help when
> doing regression tests (when not using the git bissect command).

I agree.

> My useless two cents

and another two ;)

Michael

[1] http://dicom.offis.de/download/dcmtk/snapshot/

-- 
OFFIS DICOM Team, Escherweg 2, 26121 Oldenburg, Germany
E-Mail: dicom at offis.de, URL: http://dicom.offis.de



More information about the Ctk-developers mailing list