I think this issue is being conflated. While swift is evolving so drastically between versions most library authors are just dropping support for previous versions when they update to a new version and I think this will still be the case until module stability becomes commonplace. "Most" is just my opinion as I haven't done any real investigation and have just seen several popular SwiftPM packages that have been around since at least Swift 3 that in the past and even today have always only supported the latest version of swift and as such have also only had a single Package.swift.
From this observation, I personally think it is not as big a deal as it seems. I recognize that it will definitely affect some people, but the underlying issue is not with this pitch.
This does hold weight and is why I said earlier:
I'm going to keep arguing for keeping it in a single location where other metadata could be reused because I view the benefits of (probably) most people reusing metadata from the manifest as outweighing the cost of having the functionality in SwiftPM, but I do see the value in having a separate metadata file instead. I'll honestly be happy with whatever is decided, as long as something is decided.
As an co-maintainer of SwiftProtobuf our policy has always beed to support back one full Swift version (so as of 5.0, we support back to 4.0 toolchains). If a library is doing networking/parsing of foreign data/etc. on client devices, then you can't always assume your customers will be able to updated to the latest/greatest at any time. You might have a security fix and you need to ensure adoption of your update is as easy as possible, so either you support back old versions and/or you also commit to porting fixes to older branches. For our library, it is has been easier to ensure we support older versions so clients can update on their schedules.
I know that this would affect some people, but regardless of whether or not the metadata were to be added in swift-tools-version: 6.0, you would still have to support a new version of SwiftPM after the update. Adding the ability to set metadata in the Package.swift does not change this. Therefore this is not directly an issue with this pitch per-say, but with SwiftPM. Or are you saying that you would be opposed to any and all updates/changes to SwiftPM period? (at least ones requiring a new version of SwiftPM that you have to support)
As @Aciid pointed out, there is one potential idea to resolve this issue which would mitigate many of the issues with maintaining multiple Package manifests (it would at least all go into a single file instead of several).
If there were a solution in SwiftPM which resolved the issue of maintaining separate Package.swift files for multiple SwiftPM versions, would that alleviate the majority of your concerns with placing the metadata in the Package.swift?
I don't follow, all we'll have to add is .version("6"). No need for a versioned package file.
Yes, it if truly resolved the need for it. There likely would be a time period where both are needed, but eventually that will window down. If that system does happen, I hope we can retire/remove the old versioning methods, if they are still needed, then that implies the new things still isn't complete, and the concerns are still valid.
Yea, no, we can support version by just listing the support versions when there aren't other changes required. The problem cases has been historically where things are added/changed in how one has to express things in the file, and that leads to the pain points with multiple versions. That's where my fears are with adding something new that has to be expressed in the file (and might take some future changes to finish getting right).
That is basically what I already did, though I was just aiming for documentation generation, not for a package index. My strategy already loads descriptions, a license and several project links, as well as the package manifest itself. If you want to experiment with it, all you would have to do is depend on Workspace, stick it in edit mode, and expose the WSProject module as a product to get access to these two methods (1, 2) and their lighter variants. It isn’t fast (especially until SE‐0226 is implemented), but it can already do what you want. If you are aiming to put together a package index, I am certainly open to exposing and adjusting the API if it can be helpful toward your goal.