Manual package compatibility result reporting #1507
Replies: 5 comments 3 replies
-
I was thinking the same with respect to the package info being at a disadvantage with builds that cannot be fixed. The problem with allowing manual configuration is it's easy for maintainers to just switch it on and forget about it when compatibility changes. I think what we should do instead is allow them to disable the matrix entirely via |
Beta Was this translation helpful? Give feedback.
-
Alternatively, we could translate some compatibility info from |
Beta Was this translation helpful? Give feedback.
-
Manual changing could make problems as @finestructure mentioned, but how about reading Package.swift file header (swift version) and platforms property array? It's not an ideal solution because we are not 100% sure that build will pass but IMO it's something between manual and automatic versions matrix. |
Beta Was this translation helpful? Give feedback.
-
Ironically, that key was our first attempt at getting this information, but it's really not ideal for a couple of reasons. First, the key is intended to be used for something a little different to indicating package compatibility. According to the docs:
Then, the values for the enum are problematic as they only cover v4, v4.2, and v5 values. Yes, there's an arbitrary string value, which people could use, but it's not great. I think if we did allow manual specification, I'd rather not abuse that key for a different purpose and do it via |
Beta Was this translation helpful? Give feedback.
-
Hi, any movement in this thread? I mean is it possible to set the compatibility matrix manually yet? |
Beta Was this translation helpful? Give feedback.
-
There are many reasons that our build system could fail for reasons that are hard to fix either by the package author or by us. One came up today, but I'm sure more already lurk undiscovered in the index.
The compatibility matrix is so prominent on the package page that it puts those packages at a disadvantage, so I wanted to discuss the potential for a manual compatibility statement.
If (and it's a big if) we do this, we should tie the results to package versions just as we do for the automated build results. This means that package authors will need to update their compatibility information manually with every release. However, giving them that task means it's more likely that results (if they exist) will be current.
I don't think we should allow compatibility for a branch, only the latest tagged beta and stable versions. We should also put a note close to the compatibility matrix indicating it's manually set rather than automated.
I can see a new key in the
.spi.yml
file that could work for this:Naturally, this will never be as good as automatic results, but it's better than no results. Or is it? That's the discussion 😂
Beta Was this translation helpful? Give feedback.
All reactions