[Ctk-developers] CTK Update to latest DCMTK

Wed Aug 3 13:36:49 UTC 2011

This discussion is a bit diverging from the the engineering side towards compilation issues.

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? 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.

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).

My useless two cents,
Ben

----- Original Message -----
> Hi all,
> 
> regarding fixed version vs HEAD I want to describe the situation for
> MITK and DCMTK here but maybe it also affects other projects using CTK
> and we could use it as a blueprint for similar situations:
> 
> - we already use DCMTK in MITK
> - some projects using MITK require fixed versions of external
> libraries,
> at least for "critical" components, and DCMTK is critical since it
> deals
> with patient and image data
> - recently we started using CTK in MITK and of course we would like to
> "share" the same version of DCMTK
> 
> In my opinion there are different solutions to this:
> 
> 1. We adapt the CTK code that uses DCMTK in a way that it supports
> both
> 3.6 and the current HEAD. Then projects using CTK could provide their
> own DCMTK and everything works. It would still duplicate the CMake
> code
> to build DCMTK as an external project, so we could maybe insert a
> switch
> in CTK to select 3.6 or HEAD.
> 
> 2. We leave the HEAD version. External projects have to make sure by
> their own testing that the required DCMTK functionality works as
> expected. Even then there should be some CMake mechanism to "freeze"
> the
> DCMTK version that is checked out.
> 
> 3. We stick to 3.6 and wait for the next official release.
> 
> I would prefer 1., but I cannot estimate how much effort this would be
> and how much functionality we would "loose" in CTK while using the
> stable version.
> For 2.: maybe the intermediate versions of DCMTK are also very
> reliable
> and stable and the "official releases" are only snapshots without
> special testing.
> 
> Another remark regarding "versions": I know we agreed that CTK won't
> have released versions soon since it is under heavy development. But I
> think we shouldn't wait too long. For MITK we are now referring to
> fixed
> version by using GIT hashes which works but is sometimes cubersome.
> The
> debian packages already have a version number (0.1-2, 0.1-3). I know
> this is very experimental, but still we could think of tagging certain
> version of CTK just as a reference point for external projects.
> 
> Ok, sorry for the long mail, please comment!
> 
> Marco
> 
> 
> 
> 
> 
> 
> 
> On 07/29/2011 12:05 PM, OFFIS DICOM Team wrote:
> > Hi Marco,
> >
> > thanks for scanning through the changes!
> >
> > Am 29.07.2011 11:57, schrieb Marco Nolden:
> >
> >>> I also changed the repository location in the superbuild to fetch
> >>> DCMTK
> >>> from the official OFFIS repository at
> >>> http://git.dcmtk.org/dcmtk.git .
> >>> That works for me here.
> >>
> >> It works, but it is rather slow, takes about 10 minutes to clone
> >> from
> >> DKFZ. I would also prefer to have an option to use an official
> >> release of
> >> DCMTK, since we do that in MITK and also use CTK there. I already
> >> commented on github, overlapping with this email, so I post the
> >> link
> >> here, maybe the others could also comment on that topic:
> >>
> >> https://github.com/commontk/CTK/commit/1414293aec6c76bc5788e3ade9979150974bc568#commitcomment-502670
> >
> > Please see some comments there.
> >
> > Regarding the clone time: I guess the server is not the fastest
> > machine and
> > also http is not really the fastest git protocol ;) Maybe we can
> > work on the
> > second issue.
> >
> > However, also consider that fetching updates will be much faster
> > once you
> > have a cloned copy.
> >
> > Another option would be to not clone all commits from the last 15
> > years from
> > DCMTK but to only clone the last 3 years or something. I did not try
> > that but guess it is possible with git (right?) and maybe leads to a
> > huge
> > speedup.
> >
> >>> Nevertheless, since these are my first actual commits to CTK, I
> >>> expect
> >>>  that I have done some mistakes, hopefully not too many serious
> >>>  ones ;)
> >>>  Please tell me and I will correct that as soon as possible.
> >>>
> >> Everything looks fine to me. There is just one "Merge
> >> remote-tracking
> >> branch 'origin/master'" commit we try to avoid in CTK by rebasing,
> >> but
> >> that was probably just an accident.
> >
> > Yes, thanks for noting and sorry for that. I should take better care
> > of this
> > in the future.
> >
> > All the best,
> > Michael
> >
> 
> 
> --
> ----------------------------------------------------------------------
> Dipl.-Inform. Med. Marco Nolden
> Deutsches Krebsforschungszentrum (German Cancer Research Center)
> Div. Medical & Biological Informatics Tel: (+49) 6221-42 2325
> Im Neuenheimer Feld 280 Fax: (+49) 6221-42 2345
> D-69120 Heidelberg eMail: M.Nolden at dkfz.de
> _______________________________________________
> Ctk-developers mailing list
> Ctk-developers at commontk.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers