Thanks for the stats Honza, that matches my manual estimates.
We probably can't expect to explicitly notify clients of API changes, my expectation is that what we should typically do is try and ensure that API changes come with as helpful a diagnostic as possible. Before Swift 3 is complete, though, my opinion is that the manifest is "unstable" (even though we haven't changed it much) and can expect clients to update on their own if/when they try a new version of the package manager.
After Swift 3 is complete, we are still going to need to change the manifest format, but we should try to be more careful and ensure API changes come with deprecation warnings etc.
On Jul 13, 2016, at 1:25 AM, Honza Dvorsky <firstname.lastname@example.org> wrote:
I agree that the name should be required. In order to better understand the impact on existing packages, I pulled some stats for how many packages currently don't explicitly specify their name in their manifest - 119 out of 2222, which is about 5 % of all packages I crawled from GitHub. The list of their names is attached to this email, so that we could potentially write a script to create an issue on their repos to notify them of this coming change.
On Wed, Jul 13, 2016 at 2:32 AM Daniel Dunbar via swift-build-dev <email@example.com <mailto:firstname.lastname@example.org>> wrote:
We currently allow:
let package = Package() // Note no name here
in a package manifest, but this turns out to be both problematic and rarely used.
I intend to move to making this required, here:
but wanted to run it past the list in case anyone has an objection.
swift-build-dev mailing list