Stepping back: what do we want from platform releases?

[Justin Bailey]

When I first began using Haskell about 2 - 3 years ago, a major
frustration for me was the number of "bit-rotted" libraries I found. I
am also a Windows user which compounded the problem, since many
libraries were not Windows friendly at the time. Finally, because I
was learning Haskell, I did not have the wherewithal to distinguish
trivial versioning errors from real problems.

Things are much better now with Hackage and cabal, but even so the
platform can provide ease-of-use and stability for those wanting to
use Haskell, but not wanting to build everything themselves. Bit-rot
can't be prevented, but the platform can help make it obvious to a
given user if a older library can still be used.

The School of Expression Graphics package is a perfect example of how
the platform could help. That package never bit-rotted but it has
changed significantly from the book and getting it working is
non-trivial. The package is also most likely to be used by newbies,
which makes using the library that much harder and off-putting.  If
the SOE package was tied to a particular platform release, then it
would be a lot easier to get it working, keep it working, and explain
to others how to use it.

I really like the idea of the platform and encourage the work on it to continue!

On Sun, May 10, 2009 at 12:34 PM, Duncan Coutts
<duncan.coutts at worc.ox.ac.uk> wrote:
> All,
>
> On reflection, we (Don and I) think we've asked a question that has too
> many assumptions behind it that are not universally agreed. Perhaps we
> would do better to look at the slightly more general issue.
>
> The question we asked about API stability in minor releases already
> assumes a lot about the frequency of major and minor releases and indeed
> what a major or minor release actually is; what their purpose is.
>
> We've actually started out backwards, we've assumed major and minor
> timetables and a version number scheme and then asked everyone what
> should fit that. Instead we should agree what the purpose of Haskell
> Platform releases are. Once we have decided that, then working out how
> frequent releases should be and the precise rules and version number
> schemes will be details that will be much easier to agree.
>
> So, what is the purpose of platform releases? Remember that we already
> have a system whereby any maintainer can make releases of their packages
> at any time and end users can download and install those releases. So
> what is the additional purpose of platform releases?
>
>      * Bundling everything into nice easy end-user installers. This is
>        certainly one purpose. For achieving just this we do not need
>        anything more than a working snapshot of packages from hackage.
>
>      * Testing. Making sure a set of packages work together.
>
>      * Getting new features into the hands of users. Not everyone wants
>        to download the latest and greatest from hackage. They want to
>        use things tested together but still want new stuff
>        occasionally.
>
> These points we think we all agree on, but none of them really tell us
> much about how frequent releases should be, as long as they're not so
> far apart that it defeats the third point about getting new features
> into the hands of users.
>
>      * Telling distributions what they should package and telling users
>        what they should have to be able to run the majority of
>        relatively recent Haskell code. These are two purposes but
>        closely related.
>
>      * Telling developers what set of libs to test against to maximise
>        their potential audience.
>
> These are about trying to make sure that users and developers are using
> the "same" stuff so that people can write programs and know that other
> people can run them. These require that the releases are the "same"
> between various operating systems (which the first 3 purposes to not
> strictly require) but more so that they should be the same between many
> users and many developers over some non-trivial period of time. This is
> the stability argument.
>
> If we agree with these purposes then we have to consider the balance
> between stability and progress in terms of new packages, new features
> and sometimes changing some things in incompatible ways.
>
> Note that these points do imply that new features (even compatible ones)
> cannot be added too frequently. Otherwise developers will write programs
> using those new features and users will not be able to run them. We
> would be asking users to upgrade too frequently.
>
> One strategy for balancing stability and change is to compress changes
> into specific points -- major releases -- rather than trickling them out
> every month. This is in contrast to Hackage which allows for very rapid
> change and feedback.
>
>      * Synchronise cross­-package changes. Reduce chaotic transitions,
>        eg switching old-time -> time, or new exceptions.
>
> This is more ambitious. This implies some community process to decide on
> these kinds of cross­-package changes and buy-in from package
> maintainers to follow through on the community decision in time for a
> particular platform release.
>
> --------
>
> So we must consider what we are asking users, distributors, developers
> and maintainers to do.
>
> Remember also that we are not preventing developers from releasing new
> features in their Hackage releases and that the platform gives end users
> the tools necessary to get those latest and greatest releases. So in
> comparison to other systems we actually have a much better release valve
> for the pressure to get new features to users quickly.
>
> Duncan and Don
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>