You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Project.snake, the metadata and resource map file for CoilSnake projects, contains a version number field. This helps CoilSnake identify if a project needs to be upgraded or if a project is from a newer version of CoilSnake and thus cannot be used.
Preview versions of CoilSnake contain some features that are not backwards-compatible with the most recent release version (such as those introduced in commit 967dd90). As a result, Project.snake incorrectly identifies preview-build projects as 4.2 projects, and will try to compile them even though it may not be able to.
The version number field in Project.snake should accurately identify what projects are compatible with what CoilSnake versions.
Ideally, version numbers should be updated as soon as breaking changes are made, instead of at release. If a new version number for every new breaking feature is unrealistic, then a dummy key (perhaps 0) could be added to the version number/name dict to indicate in-dev builds.
The text was updated successfully, but these errors were encountered:
Project.snake, the metadata and resource map file for CoilSnake projects, contains a version number field. This helps CoilSnake identify if a project needs to be upgraded or if a project is from a newer version of CoilSnake and thus cannot be used.
Preview versions of CoilSnake contain some features that are not backwards-compatible with the most recent release version (such as those introduced in commit 967dd90). As a result, Project.snake incorrectly identifies preview-build projects as 4.2 projects, and will try to compile them even though it may not be able to.
The version number field in Project.snake should accurately identify what projects are compatible with what CoilSnake versions.
Ideally, version numbers should be updated as soon as breaking changes are made, instead of at release. If a new version number for every new breaking feature is unrealistic, then a dummy key (perhaps 0) could be added to the version number/name dict to indicate in-dev builds.
The text was updated successfully, but these errors were encountered: