search

packagecontrol / st_package_reviewer

A tool to review packages for Sublime Text
MIT License
15 stars 3 forks source link

stop checking for sublime-syntax files (v < 3092) #39

Closed braver closed 1 year ago

braver commented 3 years ago

Usage numbers for Sublime Text 2 are really low and users cannot expect packages to still care if recent releases still work. Ie. nobody updates their package control entry to tag releases specifically for ST2. For ST3, 3092 is over 5 years old. Most syntax package developers fully switched to sublime-syntax files an I'd expect most will simply have dropped the ancient tmLanguage files without updating their package control entries. I don't want to bother package contributors with compatibility here: who still uses build 3083 but also downloads new packages from package control?

The build fails, but it doesn't look like something I can fix. I tried pulling in the crypto upgrade (#35) to no avail. error: can't find Rust compiler is among the errors 🤷🏻

FichteFoll commented 3 years ago

I would prefer to have this check (and the one for .sublime-color-scheme?) report the minimum required build in a separate field that other tooling, such as the PCC review bot, could process directly. The current handling of this is quite suboptimal imo.

Ideally, we could even hook this up for API usage, but that will not be able to consider conditional code with a fallback etc.

braver commented 1 year ago

Sure, we can always be more ambitious. Are there any real use cases that warrant the effort though?

I would like to just get rid of the useless noise in reviews that is always entirely ignored, because it is truly irrelevant if a new package works for ST builds < 3092. And would do the same for sublime-color-scheme.

FichteFoll commented 1 year ago

My current plan is to determine the minimum version of the package as specified in the repository and pass that as a parameter to the reviewer tool, which then ignores any warnings for earlier versions only.

Just as a heads-up: merging this PR won't have any effect on the review bot's output because the code that is used by the bot is vendored inside the packagecontrol.io repo (and then run on the server). In order to get updates with the review, we first need to switch to running the checker tool using GitHub Actions entirely. Surely at some point I'll be able to work on this …

braver commented 1 year ago

Right, moving the tests to actions would be a priority then. Maybe we can find a way to get someone who actually has time for these things on board? Then we can maybe do that first and think about additional ambitions later. Anyway, I’ll close this then, because it’s not going anywhere this way and it seems like we need focus and time more than we need ideas 😉