Mise à jour terminée. Pour connaître les apports de la version 13.8.4 par rapport à notre ancienne version vous pouvez lire les "Release Notes" suivantes :
https://about.gitlab.com/releases/2021/02/11/security-release-gitlab-13-8-4-released/
https://about.gitlab.com/releases/2021/02/05/gitlab-13-8-3-released/

  1. 06 Feb, 2016 2 commits
  2. 05 Feb, 2016 8 commits
  3. 04 Feb, 2016 1 commit
  4. 02 Feb, 2016 8 commits
  5. 01 Feb, 2016 6 commits
  6. 28 Jan, 2016 1 commit
  7. 26 Jan, 2016 3 commits
  8. 21 Jan, 2016 1 commit
    • Mathieu Giraud's avatar
      core/affectanalyser.cpp: safer p-value estimation, taking into account the central region · 2e23e720
      Mathieu Giraud authored
      As detected by @mikael-s in the parent commit, the region between V and J affectations
      was not taken into account in the p-values, yielding erroneous segmentations
      when this region was very large.
      
      Now this region is counted *both* for the computation of left and right p-values, solving
      the bug of the parent commit.
      
      This could be sometimes over-conservative : are we counting things twice ?
      In regular situations, the answer is no, as the p-values
      are eventually computed by getProbabilityAtLeastOrAbove in kmerstore.h,
      that takes into account the length of the seed.
      
      A more exact option could have been to use something like
      (first_pos_max + last_pos_max / 2) + getS()/2, but it would raise symmetry problems.
      The selected option should anyway improve the estimation in most of the cases.
      2e23e720
  9. 22 Dec, 2015 2 commits
  10. 18 Dec, 2015 4 commits
  11. 17 Dec, 2015 1 commit
  12. 12 Dec, 2015 3 commits
    • Mathieu Giraud's avatar
      core/affectanalyser.cpp: better estimation of .max_found in .getMaximum(),... · 783d0b19
      Mathieu Giraud authored
      core/affectanalyser.cpp: better estimation of .max_found in .getMaximum(), more reads as UNSEG_AMBIGUOUS
      
      Since the new flexible heuristic, introduced more than one year ago (de008a24, version 2014-07),
      the idea behind the check of the segmentation point was:
        "Do we have enough affectations in good positions ('before' at the left and 'after' at the right) ?
         We tolerate some of them in bad positions, but there must be 'ratioMin' more in good positions."
      
      However, the actual implementation of this idea was rather partial.
      As a result, the 'ambiguous' sequence added in the previous commit was falsely segmented.
      
      The new code is more symmetrical, .max_found being set to true when there are both:
       - more V at the left than V at the right, and than J at the left
       - more J at the right than J at the left, and than V at the right
      "More" is defined by ratioMin and currently equals to 2.0.
      
      A few reads that were previously segmented will now appear as UNSEG_AMBIGUOUS.
      783d0b19
    • Mathieu Giraud's avatar
      a29ad45d
    • Mathieu Giraud's avatar
      core/segment.h, core/windowExtractor.cpp, vidjil.cpp: option '-uu', do not... · 3b80f387
      Mathieu Giraud authored
      core/segment.h, core/windowExtractor.cpp, vidjil.cpp: option '-uu', do not create files for segmented sequences
      
      We start the file creation at STATS_FIRST_UNSEG.
      3b80f387