1. issue77: get rid of pathmax.

2. issue108: Heuristic values should be stored in the heuristic itself.

3. issue77: open list should not inherit from evaluator.

4. Move all public Heuristic methods into Evaluator class: issue716 and 
issue727.

5. support path dependence similar to multi-path dependence (especially
with path-dependent dead ends).

6. issue311: implement eager WA*.

7. issue505: More Aliases in driver instead of overfilling search class with
compositions: eg astar(lmcut)
-->eager(tiebreaking(sum_eval(g_eval,lmcut),lmcut))

8. Make sure that after dealing with the other points, issue182, issue339,
issue368 and msg2533 are addressed, and close the respective issues.

9. issue198: issues with multiple heuristics. In particular, all special-casing
of heuristics[0] in eager search should disappear.

10. issue407: g-bound should also work in corner cases.

11. issue407: initial nodes should go through the same tests as other nodes
when/before
being added to the open lists (e.g check for an infinite heuristic estimate).

12. Test that regular max and sum evaluators now always work as intended and
ensure they can be used on the top level. Then get rid of 
ipc_max_heuristic.

13. Review and possibly improve the handling of search progress and search
statistics.

14. issue751: store g values in GEvaluator.

15. issue675: reuse evaluation context.

Add item 15 to summary.

Entries 4., 5. and 9. in the summary are now done.

I did a quick test and sum() and max() seem to work correctly.

Going through this, I would say that we have addressed the most egregious issues
in the meantime. Of the remaining ones, I think only item #9 is severe enough to
require the "1.0" tag, and the relevant issue198 has the "1.0" tag itself, so I
don't think the tag is needed for this meta-issue any more. I'm removing it for
now, but if you disagree, we can certainly add it back in.

Item #12 sounds like something that has already been addressed and only needs
testing before we can mark it as done. Anyone want to have a quick look?

Add issue751 to agenda.

> Since we now have a summary field, I tried to move and merge the summaries from
> the discussion there. I'm not quite sure which of the points are still up to date.

Regarding point 4: the last bit that isn't done there is merging Evaluator and
Heuristic.

Regarding points 12 and 13, the underlying bugs should have been resolved with
the evaluation context changes and the heuristic caching change, but there is
still more cleanup work to do, and these points do need some more thorough
investigation to see that everything is indeed done noe.

I've updated the summary on those points.

Since we now have a summary field, I tried to move and merge the summaries from
the discussion there. I'm not quite sure which of the points are still up to date.

Sounds good.

In issue407 we discussed that the g-bound should also work in corner cases and
that initial nodes should go through the same tests as other nodes when/before
being added to the open lists (e.g check for an infinite heuristic estimate).
Maybe we can address this as part of this meta issue.

Points 1., 3. and 4. are addressed in the work in progress for issue77. (The
evaluator class hierarchy can be simplified further, but I think this will be
done as part of that issue, too.)

I created issue505 for point 7.

Let me know if I can help somehow.

I don't want to lose the references to old related issues, so let's add another
point (maybe later to be split into multiple points, but I hope some of these
will be resolved automatically after addressing 1.-7.):

8. Make sure that after dealing with the other points, issue182, issue339,
issue368 and msg2533 are addressed, and close the respective issues. I think
this covers all comments on this issue before 2014.

Changing this to a meta issue with the following list of issues:

1. get rid of pathmax.

2. Heuristic values should be stored in the heuristic itself (see issue108)

3. open list should not inherit from evaluator

4. Simplify evaluator class hierarchy

5. support path dependence similar to multi-path dependence

6. implement eager WA* (see issue311)

7. More Aliases in driver instead of overfilling search class with
compositions: eg astar(lmcut)
-->eager(tiebreaking(sum_eval(g_eval,lmcut),lmcut))

We should have a closer look on multi-path dependence in general, especially
with path-dependent dead ends.

When fixing this one, we might want to look at issue468, too.

In issue230 it was confusing that with lazy search the "best heuristic value"
output is not done for the goal state (which gives the impression that the
heuristic does not go down to 0 for goal states). This should be changed in the
revised code.

See also issue182.

See also issue368.

See also issue339.

We've already had several releases like that in the past, e.g. the 2004 IPC
version, or the JAIR paper version. But giving it a label like 1.0 indicates
some degree of "ready-to-use"  that it doesn't have due to a few major bugs and
other issues. For comparison, Silvia was always emphatic that people should
*not* use the IPC version of LAMA for experiments due to its bugs. Calling it
LAMA 1.0 would have sent a wrong message there.

My point is that the IPC version is, for all intents and purposes, a release.
We might not call it 1.0, but it will be the reference version until we release a 
proper version, so we may as well call it 1.0.
However, I don't really mind what we call which release - as long as it works :-)

Since we have code in the IPC version that is already marked to be replaced by a
proper implementation when we have time after the IPC, I vote for the IPC
version not being release 1.0.

Hmm, I think the IPC version has too many warts to call it 1.0.
But we can discuss this properly after the deadline.

I agree we should take care of this, and soon.
However, I think version 1.0 should be the IPC version, and this should be in 
version 1.1 or 2.0 or whatever.

I'm classifying this as a bug since there are several things that are wrong here
and only mostly work due to special cases, good luck, or limiting ourselves to
certain configurations.

The search code should be reviewed and revised, and the role of evaluators vs.
heuristics vs. search spaces in storing state information such as h values
reconsidered. The search progress statistics are a bit fragile, too; see e.g.
the comment in Heuristic::get_heuristic() in the latest code.

All special-casing of heuristics[0] in eager search should disappear, and there
currently is some confusion about heuristics vs. evaluators that keeps us from
correctly implementing max and sum evaluators (see issue198, which itself has
further references).

I know we shouldn't keep deferring our 1.0 release, but I think this one is
severe enough to be nominated for 1.0. For example, I'd really like to properly
support max and sum for 1.0. Thoughts?