On 10/02/13 15:36, Simon Peyton-Jones wrote:
We seem to be circling ever closer to consensus here! Yay!
Indeed! Good :-)
However, I’m not getting the bit about API changing vs non-API changing.
Firstly I don’t know which APIs are intended. The GHC API is
essentially GHC itself, so it changes daily. Maybe you mean the base
package? Or what?
I suspect you mean that a “non-API-changing” release absolutely
guarantees to compile any package that compiled with the previous
version. If so, that is a very strong constraint indeed. We do observe
it for patch releases for GHC (e g 7.6.2 should compile anything that
7.6.1 compiles). But I think it would be difficult to guarantee for
anything beyond a patch release. Every single commit (and the commit
rate is many/day) would have to be evaluated against this criterion.
And if it failed the criterion, it would have to go on a API-breaking
HEAD. In effect we’d have two HEADs. I can’t see us sustaining this.
And I don’t yet really see why it’s necessary. If you don’t want an
API-breaking change, stick with the patch releases.
So, we have a channel for non-API-breaking changes already: the patch
releases. So that means we already have all three channels!
Mark is asking for major GHC releases every year at the most, preferably
less frequently. That means major GHC releases in the sense that we do
them now, where libraries change, and a wave of package updates are
required to get everything working.
Johan, Manuel and Carter are saying that they want releases that add
features but don't break code, i.e. a non-API-breaking release, as a way
to get the new bits into the hands of the punters sooner. This is
something that we don't do right now, and it would entail a change to
our workflow and release schedule.
It doesn't mean no API changes at all - we would have to allow APIs to
be extended, because many feature additions come with new primops, or
new supporting code in the ghc-prim or base packages. The package
version policy states precisely what it means to extend an API
(http://www.haskell.org/haskellwiki/Package_versioning_policy) and most
third-party packages will still work so long as we only bump the minor
versions of the packages that come with GHC.
The GHC package itself would have to be exempt, because it contains
every module in GHC, and hence would be impossible to keep stable if we
are modifying the compiler to add new features.
Of course it's not practical to maintain an extra branch of GHC for
non-API-breaking development - two branches is already plenty. So there
would need to be an API-freeze for a while between the major release and
the non-API-breaking release, during which time people developing API
changes would need to work on branches.
Is it workable? I'm not sure, but I think it's worth a try. I wouldn't
want to see this replace the patchlevel bugfix releases that we already
do, and as Ian points out, there isn't a lot of room in the release
schedule for more releases, unless we stretch out the timescales, doing
major releases less frequently.
Cheers,
Simon
·Haskell Platform
·Patch-level releases
·New releases
if that’s so, all we need is better signposting. And I’m all for that!
Have I got this right?
Simon
*From:*Mark Lentczner [mailto:[email protected]]
*Sent:* 09 February 2013 17:48
*To:* Simon Marlow; Manuel M T Chakravarty; Johan Tibell; Simon
Peyton-Jones; Mark Lentczner; [email protected]; Carter
Schonwald; [email protected]; Edsko de Vries; [email protected];
glasgow-haskell-users
*Subject:* Re: GHC 7.8 release?
We seem to be circling ever closer to consensus here! Yay!
I think the distinction of non-API breaking and API breaking release is
very important. Refining SPJ's trifecta:
*Haskell Platform* comes out twice a year. It is based on very
stable version of GHC, and intention is that people can just assume
things on Hackage work with it. These are named for the year and
sequence of the release: 2013.2, 2013.2.1, 2013.4,...
*Non-API breaking releases* can come out as often as desired.
However, the version that is current as of mid-Feb. and mid-Aug.
will be the ones considered for HP inclusion. By non-API breaking we
mean the whole API surface including all the libraries bundled with
GHC, as well as the operation of ghc, cabal, ghc-pkg, etc. Additions
of features that must be explicitly enabled are okay. Additions of
new APIs into existing modules are discouraged: Much code often
imports base modules wholesale, and name clashes could easily
result. These should never bump the major revision number: 7.4.1,
7.4.2...
*API breaking releases* happen by being released into a separate
channel when ready for library owners to look at them. This channel
should probably go through several stages: Ready for core package
owners to work with, then HP package owners, then all package
owners. I'd imagine this is a several month process. At the end of
which, the release can go into the main channel. Such a merge
shouldn't happen more than once a year... I think even once every
two years is fine (!) To avoid confusion, I'd suggest that while in
the separate channel, these release be named with odd number: 7.9,
7.11,..., and when moved to the main channel renamed to even: 7.10,
7.12...
This idea of three channels needs to be much more clearly communicated.
The warning on the download page is a failure: Googling "ghc" takes you
to the home page of GHC which immediately trumpets the "Lastest News" of
a release of GHC 7.6.2. Once a user has read that and decided to
download, then "STOP!" box is a) going to be skipped as they scan for
the download link, and b) if read and followed, causes the "WTF? Why is
HP so back rev?" So we need to change the front page so that the three
channels are clearly communicated and targeted at the right users.
- Mark
(BTW: The first few links on the GHC web site are out of date: The
second nav link is to a survey that is 7 years old. The License page is
8 years out of date. The FAQ is over a year old.)
On Sat, Feb 9, 2013 at 8:24 AM, Ian Lynagh <[email protected]
<mailto:[email protected]>> wrote:
On Sat, Feb 09, 2013 at 12:06:12PM +0000, Simon Marlow wrote:
>
> As a straw man, let's suppose we want to do annual API releases in
> September, with intermediate non-API releases in February.
That's a non-API release 5 months after the API release.
6.10.2 was 5 months after 6.10.1 (.3 was 1 month later, .4 a further 2)
6.12.2 was 4 months after 6.12.1 (.3 was 2 months later)
7.0.2 was 3.5 months after 7.0.1 (.3 was 1 month later, .4 a further 3)
7.2.2 was 3 months after 7.2.1
7.4.2 was 4 months after 7.4.1
7.6.2 was 4.5 months after 7.6.2
so if we do non-API releases, then perhaps it would make sense to stop
doing minor releases (unless a release turns out to just be broken).
Thanks
Ian
_______________________________________________
Glasgow-haskell-users mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
