[m-dev.] New release?

[Paul Bone]

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
release-to-release.

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
be.

> 
> 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:

https://www.mercurylang.org/bugs/roadmap_page.php

> 
> 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