[m-dev.] New release?
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
> 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
> 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:
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
> 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.
More information about the developers