4.1.5
  - Updated codebase for Dfam 3.7 compatibility (famdb format 4.3)
  - Penelope classification change caused *.tbl file accounting
    to place them in the Unknown category.  Also fixed landscape
    generation tool.
  - Added a new utility to merge *.out *.align files generated by
    running RepeatMasker serially.
  - Repbase Metadata is seriously out-of-date, updated species names
    so that they match the current NCBI Taxonomy names.
  - Fixed an issue with the HMM parser.  It wasn't recognizing 
    negative values for Tau with models that do not have GA thresholds.

4.1.4
  - Added support for RMBlast 2.13.0
  - Release of the TE genome browser visualization (UCSC) and trackhub
    generation tool.
  - New CpGSites and unadjusted Kimura stats in the *.align file.
  - Fixed a bug that caused the read-only state of the input fasta file
    to propogate to the intermediate files and cause the program to exit.
  - Removed DateRepeats as it's based on old library formats - this functionality
    will return with the refactored version of RM in the works.

4.1.3-p2
  - A recent change in 4.1.3 to correct blank fragment ID fields can in rare
    cases causing the error message: 'Can't call method "setLeftLinkedHit"'.
  - The RepeatAnnotationData.pm file containing necessary information for
    recognizing equivalent fragments of DNA transposons was missing data.
  - The MULE-MuDR class was added to the *.tbl file for "-lib" searches.

4.1.3
  - A new utility for generating trackHubs for our new UCSC TE visualization
  - Fix a bug where killing RM while starting up can leave the cached libraries
    in an inconsistent state. 
  - Fixed a bug where in rare cases the joined fragment ID field is blank
  - Merged in changes to Dupmasker supporting multi-threaded use
  - Fixed legacy RepBase taxonomic labels
  - Added support for GFF v3 output and fixed the utility/rmOutToGFF3.pl

4.1.2-p1
  - Releases 4.1.1-4.1.2 contained a bug with the processing of Alu sequences 
    in primates. The step where an initial annotation is refined into a 
    particular Alu subfamily was not performed and the annotations remained 
    labeled with the initial capture sequence ( AluJb, AluSx, or AluY ). 
    This patch release fixes this one issue.
  
4.1.2
  - Fixed 21 protein family classifications in RepeatProteinLib.
  - Fixed a problem with the generation of the RepeatMasker.lib file for use by 
    RepeatModeler. In release 4.1.1 it did not add the classification info to 
    this auxilary file.
  - Fixed a "log(0)" error that can cause the program to fault in rare circumstances.
  - buildSummary now supports FamDB and has improved documentation.
  - Bugfixes and improvements to FamDB.

4.1.1
  - Dfam (starting with version 3.2) is now distributed in the FamDB file format 
    based on HDF5, which has improved support for large datasets compared to the 
    EMBL and HMM formats that were previously used. RepeatMasker therefore includes
    a copy of famdb.py, and depends on the python package h5py.

      o The 'configure' script and other parts of RepeatMasker have been updated to 
        accomodate these changes.
      o The utilities 'queryTaxonomyDatabase.pl' and 'queryRepeatDatabase.pl' are no 
        longer included, since that data is now included in FamDB. The 'famdb.py' 
        tool can be used to make many of the same queries as the removed utilies, 
        and even more.

4.1.0
  - Refactored the RepeatMasker configuration system.  
    The changes make it easier to automate installation and/or
    bundle RepeatMasker.

4.0.9-p2
  - Another improvement in TRF error handling

4.0.9-p1 : Tue Apr 16 08:51:22 PDT 2019
  - Input files containing multiple FASTA sequences
    caused RepeatMasker to error out with a message
    like:

      "WARNING: TRF returned an error (Return code = ### )
       TRF parameters: 2.7.7.80.10.50.10
       A search phase could not complete on this batch.
       The batch file will be re-run and if possible the
       program will resume.
       WARNING: Retrying batch ( 1 ) [ 255,, 195]..."

    This bug was introduced in an attempt to improve TRF
    error catching.  Unfortunatly the return codes are
    not documented for TRF and the assumption that 256
    is the only successful return code is wrong.  The
    "success" code appears to change depending on the
    number of sequences in the file.  The workaround is
    to fail only if there is a message in the error output
    file.

