Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

travis: Document why we test the GHC versions that we do #124

Closed
petertseng opened this issue Apr 7, 2016 · 5 comments · Fixed by #174
Closed

travis: Document why we test the GHC versions that we do #124

petertseng opened this issue Apr 7, 2016 · 5 comments · Fixed by #174

Comments

@petertseng
Copy link
Member

For example #82 explains that we test 7.6 because some versions of Linux use that. An example I found was that Ubuntu trusty uses 7.6. It would be good if we would express the rationale as comments in the .travis.yml file so that we may potentially answer questions such as "when is it safe to remove our support for 7.6?"

To be clear, not that I'm advocating removing support of 7.6 anytime soon. In fact I may even advocate for adding 7.4, since I found that Ubuntu Precise ships with that.

Edit: Indeed I still would have advocated for 7.4 but experiments in #131 to try to get 7.4 working were unsuccessful. (no mkdtemp in System.Posix.Temp in the version of unix we get with 7.4).

@rbasso rbasso mentioned this issue Jun 18, 2016
4 tasks
@rbasso
Copy link
Contributor

rbasso commented Jun 20, 2016

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
Copy link
Member Author

petertseng commented Jun 23, 2016

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
Copy link
Member Author

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
Copy link
Contributor

rbasso commented Jun 23, 2016

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.

@petertseng
Copy link
Member Author

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants