Running an index command in the CLI would abort if stack graph construction for one of the indexed failes failed.
This may be fine when debugging a spec, but too punitive for users, who would like as much partial information as possible in the database, even if some files are not covered by the spec, or bugs exist.
This PR changes the behavior to mark those files as failed (as we already do for files with parse errors) but continue with the remaining files.
Fixes #418.
Note that I've also bumped the version already, even though I'm not sure if I'll release right away or not.
In the past we'd only bump the version right before a release, which sometimes resulted in confusing situations when depending on the repo instead of released version.
The versions would still be comaptible, even thought he source already contained incompatible changes.
My idea is to make sure the version in the source always reflects the changes w.r.t. the last release.
Running an
indexcommand in the CLI would abort if stack graph construction for one of the indexed failes failed. This may be fine when debugging a spec, but too punitive for users, who would like as much partial information as possible in the database, even if some files are not covered by the spec, or bugs exist. This PR changes the behavior to mark those files as failed (as we already do for files with parse errors) but continue with the remaining files.Fixes #418.
Note that I've also bumped the version already, even though I'm not sure if I'll release right away or not. In the past we'd only bump the version right before a release, which sometimes resulted in confusing situations when depending on the repo instead of released version. The versions would still be comaptible, even thought he source already contained incompatible changes. My idea is to make sure the version in the source always reflects the changes w.r.t. the last release.