[m-dev.] New release?

Paul Bone paul at bone.id.au
Wed Oct 21 10:49:02 AEDT 2015

On Wed, Oct 21, 2015 at 10:25:57AM +1100, Julien Fischer wrote:
> Hi Paul,
> On Tue, 20 Oct 2015, Paul Bone wrote:
> >Simple question, difficult answer..
> >
> >Is now a good time for a new Mercury release?
> It's certainly time we had another one; the GC upgrade was the main block.
> >Last time Julien and I spoke about this, quite a while ago, I recall that we
> >wanted to upgrade Boehm GC first.  Now that that is done is there any other
> >planned changes that we'd like to wait for?
> Before we branch we need to finalise the break-up of the standard library's
> 'term' module, as per the following thread
> <http://www.mercurylang.org/list-archives/reviews/2015-February/017741.html>.
> In particular, the type term.context/0 needs to be moved to its own module.
> Bug #357, "Parallel conjunction broken on OS X" is a showstopper.  The
> actual situation is worse than described in that bug report, _none_ of the
> .par grades currently work on OS X.  (They worked in 14.01.)

I've also been having trouble with parallel conjunction lately.  I'm not
sure what's changed as I haven't looked at this for a while.  Although very
few people use this feature, I'd still prefer to avoid regressions from

These types of bugs can probably be fixed on a release branch and merged
back into master.  That said it still makes sense to wait before branching
for Zoltan's change, to avoid making that more difficult than it needs to

> In addition, the following bugs really ought to be resolved before
> any release:
>    * Bug #278: Compiler crash from bad state variable use.
>    * Bug #373: string.to_float imprecisely specified.
> (There's almost certainly some other bugs that we would ideally address as
> well.)
> There's some more standard library issues that aren't currently in the bug
> database, for example float.round_to_int/1 and friends have inconsistent
> behaviours across different backends when their argument won't fit in an int.
> (I'll add an entry to Mantis for this.)

Hrm, I'd like to try making a "TODO list" of bugs to fix for the release.
I suggest tagging bugs in Mantis with the release name then using the
roadmap feature as a TODO list.  I've added #357 as a test:


> There was a list of things we wanted to do to address the "too many grades"
> problem.  Some of these have been done (e.g. hiding user facing documentation
> for experimental grade components), others haven't yet (e.g. merging the 'tr'
> and 'trseg' grade components and renaming the grade component options).  See
> the following thread:
> <http://www.mercurylang.org/list-archives/reviews/2014-September/017297.html>

When this came up recently Micheal (despite how he raised the issue) made a
good suggestion that we should document not just what the grade components
mean (which mostly exists in the user guide) but which combinations make
sense / are supported / are well tested.  For example it's not obvious to a
new user that hlc.gc.stseg does not make sense.

This was one of the reasons I setup the wiki.  There were a bunch of reasons
but this was the one that actually got me to do something.  It has has very
few contributions but zero spam, so I think that there's still potential
there.  Anyway, my point is that some of the "too many grades" solution is
orthogonal to making a release.

> >I've noticed that Zoltan has been doing a lot of refactoring.  Is it best to
> >wait until this settles down and has been tested in ROTDs for a little
> >while?
> Answered elsewhere in this thread.
> >Or is that what the release candidates/betas are for?
> Ideally, they are not for testing large scale restructures such as the ones
> Zoltan has been working on.  We will need to let things stablise first.

Agreed, not the large scale stuff.

Paul Bone

More information about the developers mailing list