Stepping back: what do we want from platform releases?

[Duncan Coutts]

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