Finally done.

BTW, regarding the usage message, some evidence for this convention is on

    https://en.wikipedia.org/wiki/Usage_message

which uses the bash equivalent of os.path.basename and sys.args[0]:
"$(basename "$0")". I think it was either Jendrik or Florian that first brought up this convention among us.

Thanks! Looks, great.

I answered your comments on github.

Here you can see the rendered file: https://github.com/silvansievers/downward/tree/issue1003

I like the organization of the requirements in the README file. Is there a way to see what it actually displays like now on github (i.e., the rendering, not the Markdown source)?

Pull request, to have a change of requesting more changes: https://github.com/aibasel/downward/pull/24

I moved the Requirements page to ForDevelopers and added notes at other places.

Regarding ObtainingAndRunningFastDownward, there already exists an issue to migrate the information there to the code repository: http://issues.fast-downward.org/issue961

Unless someone requires more changes, I'll merge this issue later today, after the reading group.

What do we do with the remaining TODO item here? What do we do with www.fast-downward.org/Requirements? Should we try to update/improve the wiki, possibly moving more information into the repo's readme? 

Other than that, this issue can be merged.

I'm also done with the requested changes. I forgot if we came to a decision regarding when to run/not to run the Github actions. I still don't feel the need to restrict them running by default.

Done.

> @Silvan: yes, rebasing sounds like the easiest option. But do whatever works for you. In any case, we could also add the list of tested versions to the repo within your pull request already. (Of course, this wouldn't solve this issue of deciding about the rules, but only document the status quo.)

I would suggest to not rebase because this issue now mainly deals with improving the Github actions. Can you please add your suggested documentation file within my branch? You have access. I'm also updating the title of this issue to reflect that the largest work by far went into the Github actions.

I agree with Silvan.

Fine with me.

I think we should open separate issues for increasing requirements, such as for CMake or adding support for Python 3.9. This issue is about fixing the rules, collecting the current requirements and documenting the status quo (which likely violates our rules) and, as a new item, to fix our Github actions to test what we currently require/support.

I'm not sure if this is possible. As far as I know, cmake_minimum_required is the first thing that is checked at the start of the file. Not sure if CMake has the information about the OS at this point and can make a switch based on that. But it's worth a try.

If we do make the switch to CMake 3, it would be nice to fix this as well:
https://github.com/aibasel/downward/blob/main/src/search/CMakeLists.txt#L16

Thanks for the clarification! I suggest to set "cmake_minimum_required" depending on the OS then: for Windows we use 3.12 and for all others we find a version that doesn't trigger the "deprecated version" message that Silvan mentioned. I'd try  version 3.5 (from Ubuntu 16.04).

I'm fine with increasing the minimum CMake version but if Ubuntu 18.04 comes with 3.10 and we set it to 3.12, it will not compile there. CMake is more strict about this than g++, as far as I know. The CMake scripts explicitly say which version they need to run and if the version you have is not higher than that version, the build stops. With the patch as it is, we say we only need 2.8 but then set an option from 3.12. On an older CMake, this would either lead to an error or be ignored. And if I understand correctly, ignoring the flag would break the build.

@Silvan: yes, rebasing sounds like the easiest option. But do whatever works for you. In any case, we could also add the list of tested versions to the repo within your pull request already. (Of course, this wouldn't solve this issue of deciding about the rules, but only document the status quo.)

Good point, yes. I think we should increase the required version of CMake anyway because 2.8. will expire "soon", at least I keep getting such warnings.

Jendrik, I'm done with my changes on the Github actions. How do we proceed here? You wanted to create a pull request for adding information to the repo. Since I somewhat hijacked this issue for something else, should I just rebase the changes to the actions to the main branch so you can take the branch issue1003 for your pull request?

The requirement/support for CMake is currently listed as "3.10.2 through 3.16.3" but in the CMake files, it shows as "cmake_minimum_required(VERSION 2.8.3)". I also saw that in the pull request for issue1005 there is a new line "cmake_policy(SET CMP0074 NEW)" which requires CMake 3.12.

I noticed that the Github actions didn't properly test everything we wanted to test. After way too much time being annoyed with Windows shell problems, we now also test both available Windows versions, among others. If we agree on the requirements in the wiki, then I would merge the fixed actions.

Furthermore, we need to discuss where the information should live. Jendrik suggested to have the requirements directly in the repo so that the information has to be maintained when working on the code. I sign this suggestion and would go even further and think about getting rid of/replacing http://www.fast-downward.org/ObtainingAndRunningFastDownward.

This is not strictly speaking part of the sprint, but as we discussed this only recently and we also need to do a release soon, I think it would be good to continue working on this.

We discussed which versions we want to support. I added a new page on the wiki: http://www.fast-downward.org/Requirements Please add whatever is missing.

I don't think it should stay there necessarily, but we should rather consolidate this new information with the old page http://www.fast-downward.org/ObtainingAndRunningFastDownward which is not really up to date. Any suggestions on what to document where?

I don't think we need a page which explains how to get the code, how to compile it and how to run it. Getting the code is obvious since the code lives on github. Compilation instructions are useful. I'm not sure how useful the sections on running and "known good domains" is.

When working on Github actions (issue940), we realized that we don't have clear rules regarding which versions of compilers, Python and operating systems we currently support with Fast Downward. This issue is intended to change this. In particular, we want to come up with rules regarding which versions to support and when to change the requirements.

Regarding when, one possibility would be to combine this with releases. Then, we would not only have clearly defined requirements for each release, but also a clear time point when we possibly increase the required versions. Of course, it could still happen that we would need to change requirements when working on a particular issue and this should still be possible.

Regarding on "how" to change requirements, i.e., finding good rules, we thought that we should discuss this in the next Fast Downward meeting.

After deciding on rules, we also want to document which things need to be adapted when changing the requirements (such as buildbot, Github actions, wiki, release workflow and possibly more).