After discussion in the Fast Downward meeting today, we decided not to go for this for now because of the balance of advantages or disadvantages. Closing this issue, feel free to reopen if you want to make a case to go for this.

Ahh, yes, that would probably work.

> Update on the 5th point: Github respects the properties in .gitattributes that we added
> in issue974. This means that releases created after issue974 is merged will ignore the
> correct files. Unfortunately, I see no way to fix this for releases 19.06 and 19.12
> where the git attributes do not exist yet.

Can this not be fixed by backporting the .gitattributes files to the 19.06 and 19.12 branches and moving the 19.06.0 and 19.12.0 tags to the resulting commits? But we don't have to worry about this now.

Update on the 5th point: Github respects the properties in .gitattributes that we added in issue974. This means that releases created after issue974 is merged will ignore the correct files. Unfortunately, I see no way to fix this for releases 19.06 and 19.12 where the git attributes do not exist yet. 

For an example, see https://github.com/aibasel/florian-downward/releases. The release 19.12 is our normal release (before issue974) and the automatically generated tarball contains the directory "experiments". The release "testing code export on release" is created off of the issue branch disregarding our normal workflow. It respects the attributes and does not contain "experiments" in the tarball.

[Copied from the discussion of issue974. This refers to the second bullet point in Jendrik's list in msg9486.]

BTW, a possible solution to the 19.06.0 issue is to have the tag be named 19.06. We said this would clash with the branch name, and it does. But we could use separate naming conventions for release branches and released version tags, for example "release-19.06" for the branch and "v19.06" for the tag. (Just an example of a possible convention.)

We discussed moving the releases from the wiki to GitHub. For now, we only link to the wiki, but we might move the releases to GitHub later. Therefore, this issue is currently more of a discussion and a place to remember our offline discussion than a "wish".  

Some problems that stopped us from embracing github releases more were:

- The releases page is cluttered with all non-release tags.
- The automatically generated tarball is named after the tag, which does not match our convention for normal (non-bugfix) releases: it uses 19.06.0 instead of 19.06.
- Having the data on github instead of our servers makes us more reliant on them.
- Having the full description of a release on the release page means that only one the latest release is visible (the next is on page 2).
- github's tarballs/zip files are automatically generated as a snapshot of the tagged version, but we would like to filter out things like the experiments directory. Marking things as excluded for release appears to be possible in principle in git, and github would presumably honor this configuration, but we haven't looked into it yet.
- It would be good not to have two separate authoritative sources for our releases, so depending on how completely we move the release info over to github, we need to do some work to migrate the existing releases.