[I've reordered your post a bit to make my replies fit together better. I don't think this affects the sense of what I quote, but apologies if so.]
Yitzchak Gale wrote: > In addition, in my opinion it always should be possible to backport > at least the current stable version of darcs to any version of Debian > that is still supported - including even old-stable, as long as it > has not officially reached End-Of-Life. I still have several virtual > servers on old-stable that have not been de-commissioned yet. > (Currently working on getting rid of one of them.) > > I don't think it needs to be supported to build HEAD on old-stable, > though, only the current stable version of darcs. For darcs, HEAD becomes stable every 6 months, so that doesn't offer much of a window for them to safely diverge. Note old-stable is currently etch and would have reached end of life in February 2010 (http://wiki.debian.org/DebianOldStable says a year after the release of a new stable, and lenny released in February 2009). So following this policy would have implied keeping 6.6 support in HEAD until the 2.4 release branch forked at the end of December. > The good news is that Haskell support on Debian and other Linux > distributions is improving dramatically. I think that the burden of > backward-compatibility on LInux will gradually but significantly > reduce with time. I think that the Debian release frequency means that there will always be times when Debian Stable is two or three releases behind GHC. In particular, Lenny has GHC 6.8. In theory, because it released in February 2009, it could have had GHC 6.10, but I imagine this might have been difficult given freeze timings and so forth, even if the currently rather well organised Debian Haskell team had been in place back then. GHC is now on 6.12. Let's guess that Squeeze will release late this year/early next year (freeze in 2-3 months then ~6 months from freeze to release), by which time 6.14 will be out. That would leave us briefly supporting 4 versions of GHC just to work with Debian stable, and if we also adopted the "until old-stable is EOL" policy you mention that would take us past the 6.16 release, i.e. 5 versions of GHC. >> Dumping old GHC would make me happy. > > Yes, supporting a range of platform versions is not easy. > > But darcs is version control - people's data is at stake. > We need not only the ability to reconstruct our data with some > time-consuming process; we need the ability for our data to be > actively and conveniently accessible on all platforms that are in > active use. > This is indeed an important issue. GHC itself maintains backwards compatibility with itself for a long time (i.e. you can build a recent GHC with quite an old one), which makes me wonder if we could instead rely on backporting GHC itself to old Debians. However, the GHC Debian packages will no doubt move forwards in ways that makes backporting them difficult, e.g. by relying on recent features of the Debian packaging system. I doubt darcs developers will be motivated to maintain GHC backports, and we can't expect the Debian Haskell people to help out significantly with this. I don't really know where I stand on this. I do know that old GHC is sometimes quite a significant burden on development, especially when I need to build with each version we support to check that changes I've made are ok - and changes that require such checks are quite common. But I do want to maintain some focus on "caring about our users", as David would put it. Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
