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
It would be easier for package authors to declare sublime version support using semantic version numbers instead of build numbers, such as ">=3.0" rather than ">=3000". I think that this would significantly reduce the number of package submissions that declare the wrong version (e.g. 3000 when the package includes a sublime-syntax). Developers targeting dev builds could still declare them.
The text was updated successfully, but these errors were encountered:
The downside is that we'd require a lookup table for all previous and future release versions to translate them back to build numbers because you don't get the semantic number from the API.
I do agree that the people having to specify >=3092 is annoying, however. The same applies to .sublime-color-scheme as well, which we don't have a check for yet.
It would be easier for package authors to declare sublime version support using semantic version numbers instead of build numbers, such as
">=3.0"
rather than">=3000"
. I think that this would significantly reduce the number of package submissions that declare the wrong version (e.g. 3000 when the package includes a sublime-syntax). Developers targeting dev builds could still declare them.The text was updated successfully, but these errors were encountered: