travis: Document why we test the GHC versions that we do about haskell

[petertseng]

Hmm, I'll take a look at #162 by the weekend and see if that affects the plans for this and only proceed with the PR to the readme if it's still relevant!

[rbasso]

Do you think something like this would be enough?

matrix:                  # Some, still used, major linux distros pack
  include:               # old GHC versions, so we test them too, to
                         # make the Haskell track more accessible.

    - env: GHCVER=7.6.3  # Minor version released on 2013-04-21.
      addons:            # Debian stable (jessie).
        apt:             # Fedora 20 and 21.
          <<: *apt       # Ubuntu 14.04 LTS (trusty).
          packages: [ghc-7.6.3, *cabal]

    - env: GHCVER=7.8.4  # Fedora 22, 23 and 24.
      addons:            # Ubuntu 15.10 LTS (wily).
        apt:             # Stackage's snapshots from lts-0.0
          <<: *apt       # to lts-2.22 use ghc-7.8.x.
          packages: [ghc-7.8.4, *cabal]

    - env: GHCVER=7.10.3 # Debian testing (strech).
      addons:            # Ubuntu 16.04 LTS (xenial).
        apt:             # Stackage's snapshots from lts-3.0
          <<: *apt       # to lts-6.4 (latest) use ghc-7.10.x.
          packages: [ghc-7.10.3, *cabal]

    - env: GHCVER=8.0.1  # Newer versions of the Haskell Plaftorm.
      addons:            # Stackage's nightly snapshots.
        apt:             # Most haskell programmers are probably
          <<: *apt       # running this or ghc-7.10.3.
          packages: [ghc-8.0.1, *cabal]

[petertseng]

This all seems good to me, calling out the specific distros gives a good idea of the rationale.

One thing I personally might add is an answer to the question "So, why aren't we testing earlier versions such as GHC 7.4.x?".
If you asked me to write the answer to that question I would write something like:
We use mkdtemp from System.Posix.Temp, the binding for that was added in unix 2.6.0.0, which ships with GHC 7.6.x. Well, can't put links like that in YAML comments, but something that conveys the same.

By the way if anyone reading can find a way to get around that, I would be pleased to see it, but I suppose that's a discussion for another day =D

[petertseng]

If you ask why I didn't just add my thoughts to the README right at the time of making this issue, I suppose I was hoping for some insight on why things the way they are currently, and also unsure I was the one who should be setting the policy for the future.

But, I suppose the best that can be done at this point is to try to do our best to understand why things are the way they are (this seems to have been done) and make the decision that makes sense for maintainers of, and contributors to, this track. And we can change our minds in the future if there is good reason to.

So, seems no more need to dilly-dally. I will be in a position to submit a PR this weekend. Of course I would absolutely not object to being beaten to the punch if someone else submits it.

[rbasso]

So, seems no more need to dilly-dally. I will be in a position to submit a PR this weekend...

Perfect!

Unless... you think this is a good idea! If we take that route It would solve this issue, #129 and #153.