Added a --version as a command line option, this addresses issue #
Merge pull request #94 from dillonl/master

Added a --version as a command line option, this addresses issue #
Resolved issue #105
Merge pull request #106 from dillonl/master

Resolved issue #105
remove spurious "reset" of hasMoreVariants flag

This will cause us to run indefinitely in some contexts.
improve error handling by naming the failing alignment
Setting Release-Version v0.9.16
represent GLs in full dynamic range

This can be really important when we are working with somatic calls.

There is no reason that I know of to cap the GL representation, although it
should help some with compression in data that is predominantly GLs.

I haven't instrumented an option to enable this from the command line, but the
capping is controlled by Parameters.limitGL. When set to 0, it uses the full
dynamic range. When set to any other negative value (in log space) it bounds so
that value.
resolve #109 don't always pick the "best het" combo

As freebayes used to be used solely in a discovery context, the maximum
posterior genotyping including any non-reference alleles has been the default
output of freebayes.

The quality scores of such sites tend to be very low, and so they are often
filtered out and ignored. This has protracted the confusion, however, because
in targeted genotyping you want to know the precise genotype for every sample.

It is better to output the MAP genotyping regardless of whether or not it has
variation in it. This simplifies a number of use-cases and is more
straightforward, matching users' expectations about how the method should
perform.
Setting Release-Version v0.9.17
resolve #98: allow long haplotype detection with --haplotype-basis-alleles

In the past, --haplotype-basis-alleles was used for targeted genotyping in e.g.
1000G phase 3. A number of problems were shown to arise when allele
observations not in the haplotype-basis input were were forced into reference
space, so I made a change a year ago that treated these as if they were
uncalled bases, or Ns (ALLELE_NULL in freebayes internal terminology).

However, this introduced a new issue, which is that long haplotype detection
over a targeted set of alleles was now broken, as the null allele breaks the
haplotype in the semantics of the system.

At the same time, improvements in --variant-input now mean that this method can
be used for targeted genotyping. The haplotype-basis method is now free to be
used specifically for the contiguous phasing of local regions based on a set of
input alleles. This change resets the algorithm to behave as it did previously,
treating allele observations not in the --haplotype-basis-alleles input set as
if they are actually observations of the reference. For most applications of
this type, this is not an issue. Those wishing to run targeted genotyping at
particular alleles are encouraged to use --variant-input instead, which does
not attempt to build haplotype observations across the reads.
Setting Release-Version v0.9.18
allow direct specification of fasta file in fasta_generate_regions
A simple test script to show Freebayes' buggy region/target handling

The script first shows the correct output of various VCF + BED tools and
then runs variations on Freebayes to demonstrate the improper handling
of region coordinates on the command line and in BED files.
Revert "change to help text to reflect region spec change"

This reverts 0595cc5.

The current region handling (and also that before this change was made)
includes the end position internally but expects positions that exclude
it when reading --target BED files or parsing --region specs.
Correct a bunch of off-by-one errors related to targets/positions

A number of previous commits which switched the internally-used position
numbering were not comprehensive.  This lead to a clear inconsistency in
position handling that resulted in mishandled edge cases.

I audited the code for all uses of left and right boundaries, as well as
currentPosition.  While it's quite possible I still missed a couple
spots, this commit fixes a number of places missed in previous commits.
Most of the code, and the intent described in the latest commit
messages, uses 0-based, fully-closed positions internally (e.g. 0-1
describes the first two bases).  This is different from the external
expections of BED and chr:X-Y positions, which both use 0-based,
half-open positions (e.g.  0-1 describes just the first base).

I attempted to normalize all such internal arithmetic and comparison to
expect 0-based, fully-closed positions, while still expecting the standard
0-based, half-open positions from user input.  The edges of freebayes
convert to the internal representation as soon as possible to avoid
leaking the external representation.

Debugging and error messages printed to the user regarding
targets/regions are normalized to be in the 0-based, half-open style so
they match the input the user may have given.  Debugging and error
output regarding currentPosition still mixes reporting 0-based numbers
with 1-based numbers.  It appears to fall more or less along the lines
of "am I reporting about a target (0-based)?" vs. "am I reporting about
a VCF position (1-based)?", but the utility of the trace logs and other
debugging output is unclear to me, so I left it alone for now.  I
audited the two cases using the following greps:

    git grep -P '<<[^<]*?currentPosition(?!\s*\+\s*1)'
    git grep -P '<<[^<]*?currentPosition(?=\s*\+\s*1)'

It's worth noting the hunk in this commit which removes a check on
parameters.allowIndels, because this parameter previously affected
internal position tracking in interesting ways: when enabled, positions
were incremented by 0.5 (half a base) during each cycle.  This code was
removed in 6835a00, however, which is good since it added notable
complexity to position comparisons.