Package score does not include build status?

[mattmassicotte]

Hello Friends! What do you think about including Swift 6 readiness in the score?

And while I'm on the topic, I'm actually suprised that build sucess does not contribute in any way. I cannot have been the first person to think of this!

[heckj]

For my part, I'm relieved that build success doesn't impact scoring. ;-)

But to your specific suggestion, personally I think it's just a bit too early to add swift 6 compatibility into a package score. For one thing, we're still SUPER early days in this migration, and I think the "broad encouragement" from the existing Ready For Swift 6 provides good high level visibility that's positively re-inforceing. Adding it to a score almost feel punitive at this stage. And I suspect the transition is going to be multiple-years, even for Apple and "Swift Server" provided libraries.

(While I'm aggressive about adding that support in my libraries, they're generally "low population" projects - and I'm equally aggressive about adding useful docs, which if I could even begin to quantify in a reasonable form I'd be stumping for far-outweighing most other factors)

While I would absolutely prefer a swift-6 compatible package over one that wasn't compatible, all other things being equal, I there are other factors that I'd include in my own assessment with probably higher impact, many of those aligned with the what's already accounted in the existing package scoring.

A year from now, would it be "worth" 5 - 10 points (loosely equiv to tests, activity, release counts) to me? Quite possibly.

[mattmassicotte]

Thanks for taking the time to think though this more than me!

I agree, it makes no sense. But I do think taking into account successful builds/supported platforms could still make sense.

[finestructure]

I agree with Joe, it's a bit early to apply a "concurrency score".

As to builds, in general the score is used (exclusively) in ranking. I.e. getting a bonus in a category means a package is going to rank a little better, arguably it is regarded as a little "better". So say we have a package that supports all six currently tested platforms: is it really "better" than an iOS only package? The latter package's author would have no way to achieve a better score in that category.

Same for new packages that are on the latest tools version and can't support back to older Swift versions. So maybe we'd say any supported platform or any supported Swift version gives a bonus? It would be a very general bonus (i.e. effectively a penalty for "failing" packages in disguise). That could be a useful addition but it's more like a "not maintained" penalty.

[daveverwer]

There are two sides to this: Compatibility and data race safety.

I believe we should count Swift version compatibility towards the score, and in fact, we assigned points for it in our original score calculation!

There’s some history on why we removed that aspect of our original calculation (Spoiler: It wasn’t doing anything useful) and opened an issue to add it back, but to base the check on build information now we have it. That remains something we should do but with some additional logic applied.

The original idea was to award points if the package supported the “latest version of Swift”, and I believe a good measure of that would be the “latest shipping version of Swift”. So, once Xcode 16 is out of beta, it should award some points if there’s a green tick next to Swift 6 on any platform. If we deployed this today, we should give points for Swift 5.10 on any platform.

A separate points calculation could/should be done for data race safety since that will be a different set of packages than those that get a green tick for Swift 6 (since the Swift 6 green tick will show if the package compiles in Swift 5 language mode).

We could implement the first of these today with #1513. I’d be in favour of adding points for data race safety, too, but only when Xcode 16 comes out of beta.