I want to start off by saying that I highly appreciate each and every Swift Evolution proposal as they move forward the entire tooling suite for the language ecosystem in real ways.
It takes a lot of effort to not only design a solution to an identified problem, but also to distill it into a small enough proposal that addresses the problem without extensive changes that can be reviewed by many who might not have a full-time capacity to review and understand as well as the authors. On top of handling criticism from people who you might not know.
I also appreciate the 2nd review from trying to address the feedback given from the first review in order to reach a better solution for all involved.
That being said, I don't think the main contention of the first review has been adequately addressed.
During the pitch phase, and the first review, the community and authors' opinions have been in disagreement whether or not the collection format should be under review in some capacity as part of the commands.
The proposal has been updated to address this as follows:
Package collections must adhere to a specific JSON format for SwiftPM to be able to consume them. A draft of the JSON format has been posted in the forums, but it is not part of this proposal because it is not considered stable API. Over time as the data format matures, we will consider making it stable API in a separate proposal.
Since the data format is unstable, users should avoid generating package collections on their own. This proposal includes providing the necessary tooling for generating and consuming package collections.
In my opinion this is not an adequate answer:
- Hyrum's Law which, roughly, states: "Any observable behavior will be relied upon by someone"
- The proposal's own stated motivation is that people, such as educators and "community influencers" will produce collections
Elaborating on the 2nd point, this proposal does not provide commands to create the collection files as it claims in the updated section, so how are not machines to create these files for SwiftPM to use if they do not know what the format is?
If the data format is unstable, and going to change according to whatever force might influence its evolution, what is the point of having the formatVersion field?
I don't disagree that the data format should be considered unstable and be allowed to iterate outside of Swift Evolution as part of an incubation period for the format before a formal acceptance review.
However, given that format changes are very unlikely to change between SwiftPM versions - which are tied to Swift release cycles - why couldn't we publish the format as it stands for each version?
The proposal could have a section with the format as it is currently supported with a disclaimer:
The collection file format is not considered "ABI/API" stable between SwiftPM versions, but the current format as of SE-0291 is available for reference below.
and a document in the SwiftPM repo is maintained with the format of the collection file as it is used by a given SwiftPM release.
I think that appropriately bridges the gap between the community's concerns, as well as the authors' desire to have freedom to iterate and test.