[GenABEL-dev] Design: Versions for filevector library, change symlinks

[L.C. Karssen]

Dear list,

As I didn't get any negative responses on my proposal to start
versioning the filevector code and tagging it in SVN I will proceed to
do so.

I'd like to give the current filevector code version number 1.0.0
because it's been in production for several years and I assume most bugs
have been ironed out by now.

Any objections? Let me know!


Thanks,

Lennart.

On 09-02-14 14:13, L.C. Karssen wrote:
> Dear list,
> 
> As you may know I have been playing with the idea of creating filevector
> (more specifically the fvlib directory) a separate library (see the
> discussions at [1-3]). I also created a separate SVN branch to play
> around with that idea. Basically this would mean that packages like
> ProbABEL, DatABEL and VariABEL would get a dependency in the form of
> what I call 'libfilevector'. Especially for the R packages in the
> GenABEL suite this may not be very user-friendly because many of them
> would not have admin rights (I assume) and therefore cannot simply
> install operating system packages that contain libfilevector. Obviously
> such a change to libfilevector would be a major one.
> 
> Apart from the discussions on the mailing list this topic came up again
> a few weeks ago in a discussion with Maksim and Yurii. We discussed many
> of the pros and cons (mostly revolving around user-friendliness vs.
> technical advantages) and in the end we came up with the following:
> 
> Let's start to put versions on the filevector code. So far filevector
> has never been released separately (always as part of the ABEL
> packages). By putting a version number on the fv code and by making tags
> of those releases in SVN we can solve several issues:
> - It can be made clear which *ABEL package depends on which version of
> the filevector code
> - Improvements in the filevector code do not immediately affect the
> 'trunk' of the other packages
> - This allows packages like ProbABEL to depend on a separate
> libfilevector, whereas R packages can create a symlink to the tagged
> code instead of filevector trunk (as is the present situation)
> 
> A final advantage may be that it becomes easier to treat filevector as
> one of various file-format backends to the *ABELs. But this is something
> I'll elaborate on in another e-mail to this list.
> 
> 
> We would like to hear your opinions about this versioning of filevector
> and tagging of these official filevector releases, as well as on the use
> of symlinks to these tags by other packages (this may not be ideal, but
> it solves the user-friendliness issue, while allowing the creation and
> release of libfilevector).
> 
> 
> Hope to hear from you!
> 
> Lennart.
> 
> 
> 
> [1]http://lists.r-forge.r-project.org/pipermail/genabel-devel/2013-July/000714.html
> [2]
> http://lists.r-forge.r-project.org/pipermail/genabel-devel/2013-November/000779.html
> [2]
> http://lists.r-forge.r-project.org/pipermail/genabel-devel/2013-November/000797.html
> 
> 
> 
> _______________________________________________
> genabel-devel mailing list
> genabel-devel at lists.r-forge.r-project.org
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/genabel-devel
> 

-- 
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
L.C. Karssen
Utrecht
The Netherlands

lennart at karssen.org
http://blog.karssen.org
GPG key ID: A88F554A
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: OpenPGP digital signature
URL: <http://lists.r-forge.r-project.org/pipermail/genabel-devel/attachments/20140321/33bb1012/attachment.sig>