I vote for tie to GHC release
On Wed, Jul 2, 2014 at 10:13 AM, Mark Lentczner <mark.lentcz...@gmail.com> wrote: > Other compilers/programs generally tie the "platfrom" release into the > language and compiler/interpreter release. > > Python is a good example: 2.7.2 is the version number of both a release of > the language, the standard interpreter, and the 100s of libraries that come > with it. The librarys are not individually versioned: That is, once > something is accepted into the base set, it submits itself to be managed > and release by the core Python team. Similarly, the core Python team > includes all the libs in the release process. > > The normal packaging allows multiple x.y Python releases, but only one > x.y.z for a given x.y. So my system has on it 2.5.6, 2.6.7, and 2.7.2 on it > right now. If I load 2.7.7, it would (normally) replace 2.7.2. > > Ruby and Perl follow pretty much the same model. Of course, architecture > doesn't really come into play for these. Erlang, Ocaml, and Go don't > support (by default) versioned installs. Scala pretty much punts to the > user, letting them unpack the tarfile whereever they want... and then hand > configure environment variables! > > Most of the above languages come bundled with what we'd call the > "platform" libraries. Though how extensive those packages are varies a bit. > > Notably none of the compiler systems attempt to let the user install > multiple architectures (32bit and 64bit) at the same time. > > ==== > > So, I guess we could take on of these paths: > > *Punt:* Allow one GHC and one Haskell Platform to be installed at a time. > While we've had the directory structure to (almost) support multiple > installs, we've never really supported it. > > *Tie to GHC release: *This is easiest, because one can add, remove, and > switch between releases easily: It is just switching directories and > symlinks. Realistically, we've only ever once released two HPs for the same > GHC, and it was a point release. It is probably safe to say that two major > release of HP will never use the same compiler. > > If we go this route, the logical thing is to keep the sub directory under > /Library/Haskell named for the ghc release, but include the architecture: > That is, go from ghc-x.y.z to x.y.z-arch (which would be the same as the > compiler) - it makes the link clear. BUT, this removes the version name of > the HP: Nowhere does the tree contain 2014.2! Perhaps we should rename > Haskell Platform release to simply follow GHC: HP 7.8.3 and 7.8.3.x for > point releases? > > *Keep the independence:* As usual, Haskell is forging new ground here... > hence why we're a bit a drift. The uninstaller might just be flaky for now > if we go this route, as I'm not sure I want to spend the next two weeks > recoding that... holding up an alpha HP. > > - Mark > > > > > > _______________________________________________ > Haskell-platform mailing list > Haskell-platform@projects.haskell.org > http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform >
_______________________________________________ Haskell-platform mailing list Haskell-platform@projects.haskell.org http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
