This is all fine and well since you are the two lead developers at this
moment. However under no circumstances we should have an untested
version in /home/blast/blast
_ Please report to Anaware any changes in the library. This hopefully will
force developers to test more their products
_ We should make it a policy that it is not possible to just check things
out from CVS unless they are tested.
More at this week's meeting. Regards,
-- tancredi
________________________________________________________________________________
Tancredi Botto, phone: +1-617-253-9204 mobile: +1-978-490-4124
research scientist MIT/Bates, 21 Manning Av Middleton MA, 01949
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
On Sat, 19 Oct 2002, Chris Crawford wrote:
> hi blast'ers,
> we were having problems with the new versions of the blast libraries
> not working, and not knowing which cvs versions the older backups were
> based on. to solve this, chi and i came up with a convention for
> installing new blast libraries.
> when we have a stable version with new improvements, we will tag the
> BlastLib2 directory with the next version in the series v2_1 , v2_2,
> v2_3, ... then copy libBlast.so to ~blast/lib/spud/libBlast.so.2.1
> and link libBlast.so to libBlast.so.2.1 (also tag the corresponding
> ntuple.C with the same version number). this way, we can find the
> source code for a particular .so file, and it will be easy enough to
> revert if something goes wrong, by relinking libBlast.so.
> the current version is 2.1
> --chris
>
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:28 EST