How to handle packages without semver-valid tags?

[deathaxe]

Not all packages use strict SemVer <major>.<minor>.<patch> versions, but

1. just <major>.<minor>.
2. Date based versioning whith minor, patch being prepended with 0.

Those are flagged with "No tagged version found ..."

No tagged version found for https://github.com/kpym/SublimeLaTeXAccents

No tagged version found for https://github.com/jaabell/gmsh-syntax-and-tools

No tagged version found for https://github.com/scholer/TextToSpeech

No tagged version found for https://github.com/mcw0933/SublimeLinter-contrib-tflint

Old crawler used to be more tolerant with those quirks.

Actually Package Control 4 uses PEP440 versions.

[kaste]

I don't see tflint (https://packagecontrol.io/search/tflint) and gmsh-... (https://packagecontrol.io/search/gmsh) on the old packagecontrol.io, but they are on the new site https://packages.sublimetext.io/?q=gmsh https://packages.sublimetext.io/?q=tflint

Generally, all 4 are present on the site and in the channel. The logging should maybe be "No tagged semver version found for ...". I do not explicitly check for calendar versions, just semvers, but on the other hand be tolerant as the old crawler, or even more.

Even more maybe: Maybe "notes" should be persisted so that we can show them on the website.

[deathaxe]

You obviously miss the point of introducing tag based releases!

A fallback to branches in case of invalid tags was never intented on purpose!

Actually the original plan actually was to completely switch to tag based ones. All branch based releases exist for backward compatibility, only. New packages are accepted only when having proper tags.

The fallback to branches is explicitly not wanted as it caused many peoples environments having been broken frequently due to pre-mature pushes of unstable code to master branches. That's probably not of such a big issue these days, but anyway an upstream crawler should/must respect existing intended behaviors.

Yes, some packages seem never to have been published or picked up due to invalid tags. But that's on purpose as well.

[braver]

I don’t fully understand why we tell everyone to use semver when we actually expect pep440, but I don’t know the details of how they might overlap. I would say that indeed these are not valid tags at all and it’s very friendly and permissive that they’re included in the new crawler and website (because they previously were not). I would argue it’s overly permissive even. Is that also what you’re trying to say @deathaxe ?

Is this list of 4 exhaustive or is the list at least something that can be handled case by case? I mean we’re not letting new packages in with malformed versions, our docs very explicitly say semver is required…. Perhaps if we just weed out the anomalies that might also be a way of dealing with it?

As always with the caveat that I’m not very deep into the crawling stuff here and am just trying to look for solutions and be helpful 😊

[braver]

Note: Package versions should still follow SemVer like <major>.<minor>.<micro>
https://github.com/wbond/package_control/blob/master/messages/4.0.0.txt#L17

So, pep440 applies to libraries which are versioned that way in pypi, but packages should conform to semver still.

The question then is what to do when a package fails that requirement. The old crawler does not accept such packages (as evidenced from the examples from the OP being absent from the old site), the new one does by falling back to branch based releases. The new crawler is more tolerant that way by design. While correct use of tags is of course to be preferred, you could argue this is a nice service of the new crawler to at least get those packages out there after all.

We can't always go back and correct for such things being missed in review. We notice from time to time that package authors never notice their package not actually being included in Package Control. Maybe they don't care. These cases are invariably old packages that just never got updated anyway. From experience when reaching out to authors about such issues, some have forgotten about the package completely, most never reply at all, and a small minority take a minute to correct the situation.

So, I'm going to rephrase the issue to be a discussion around how repositories without valid semver tags should be handled, not a bug: in other words it's a matter of opinion, or interpretation of the spec, but the product works as intended.

I believe the options are:

• status quo: include the package but branch-based instead of tag-based
• old behavior: reject the package
• support malformed tags if they do conform with pep440 (but what to do if there are no tags at all)

I personally don't see a strong reason to change the status quo.

[kaste]

Locally, I have calendar versions working IIRC which the old crawler supported. Never pushed it probably also because I wanted to switch to test-driven development (as the thecrawl kind of getting official).

One thing to add here is that thecrawl feeds two things: the site and the channel. For failing packages, we want them to appear on the site at least, with the least manual support as possible from our side. Of course, generally, I'm following the be-forgiving-on-the-input-and-strict-on-the-output strategy here. A fallback -- here it is a zero cost fallback -- also is the way to show something in the normal UIs, literally: we don't need error message passing to the users or authors/maintainers, and still give a hint of something being odd.

[kaste]

Stats

• Total packages in workspace.json: 5138

• Packages with at least one calendar-style release version: 1374

• Share of packages using calendar versioning: 26.74%

• 3588 registry packages declare tags: true;
  29 of them (≈ 0.81%) still surface calendar-style release versions in workspace.json, maybe signalling the tag-crawl fallback.

---

Branch Usage

• 1326 registry packages (≈ 26.06% of the 5089 total) still rely on the legacy branch: field instead of the newer tag-based releases.

---

Fallback Packages (3)

• AlignComment — no tags
• SublimeLinter-contrib-tflint — invalid tag
• gmsh-syntax-and-tools — invalid tag

---

Actually not

• RSpec — uses calendar only for ST2
• CBP Syntax Highlighter — thecrawl bug, fixed
• CodeIgniter 3 Snippets — thecrawl bug, fixed
• Emacs Pro Essentials — uses calendar only for ST2
• ExpressionEngine Add-On Builder — uses calendar only for ST2
• External Command — uses calendar only for ST2
• I18n Rails — uses calendar only for ST2
• INI — uses calendar only for ST2
• IPython Notebook — uses calendar only for ST2
• Mercurial — uses calendar only for ST2
• Related Files — uses calendar only for ST2
• RemoteTree — thecrawl bug, fixed
• Require Helper — uses calendar only for ST2
• ScalaProjectGeneratorFacade — thecrawl bug, fixed
• SublimeCodeIntel — thecrawl bug, fixed (but also buggy registry entry)
• Twig — uses calendar only for ST2
• Typewriter — uses calendar only for ST2

---

Using really calendar-versioned tags (9)

• Dota Reborn Package
• LaTeX Accents
• PICO-8
• SimpleSyntax
• Snowflake
• TextToSpeech
• ToolRunner
• Unity Completions
• Unity Completions Light

These can be buggy as we don’t support calendar versions officially.
That means a version like 2014.12.31 will match, but a version 2014.03.02 will not (because of the leading zeros).

Fallback versions look like:

"version": "2014.11.25.09.54.52"

[kaste]

Take away: we fallback for 3(!) packages which is not an issue at all.

We regress for 9 packages which is statistically not an issue but disappointing anyway. For these I have a patch in a local branch, supporting calendar versions. If we support them, we can also tell that we do IMO as there is nothing really bad about them. (Since we always install the latest thing anyway, any counting number would suffice as well, version 154, 155... I'm okay with that too, version schemes are way below tabs vs spaces, or: which line endings do we use here, in my world. As long as I -- as a human -- can read and interpret them.)