[Proposal] SSM-0001: `swift-metrics-extras` public API redesign

Server Development
,
1

Hi all,

The proposal [SSM-0001] Public API redesign for swift-metrics-extras is now up and In Review.

The review period will run until Dec 2nd - please feel free to post your feedback either as a reply to this thread, or on the pull request.

Thanks!

4 Likes
2

Thank you for posting @kukushechkin, here’s a few notes:

Technical direction

This is all solid, looks good, let’s do it :slight_smile:

Why 1.0 “-extras”? Should this become swift-system-metrics or some other name?

You rightly observe that the only feature this package has is “system metrics”, and your overall proposal to decouple it from MetricsSystem sounds fine as well.

However, this brings me to the key question: why 1.0 the “swift-metrics-extras” package (as is) at all? It is not what we actually want from this package, and in general the extras packages are causing us headaches in terms of versioning anyway.

Why wouldn't we–if the goal is to 1.0 the system metrics–changing the package to become the system metrics package, and then 1.0 that new package? This way we avoid proliferating this "grab bag" of potential features which are problematic in the long run.

The problem with “-extras” packages is that it could contain “anything” and the future directions you listed, don’t really account for that; they’re preparing for a future where this is “the system metrics package”, what if someone invented some random feature and wanted to contribute it, we’d be likely to say “no” and that they can do it in their own package.

TL;DR;

Agreed on the technical direction, but we should consider ending the -extras package and giving this a name appropriate to its purpose and roadmap. I see “killing off” the extras package as a net win, and we set a cleaner path forward for the actual systems metrics package.

4 Likes
3

I agree the -extras name is not very descriptive, and the new name should be swift-system-metrics (unless there would be a better alternative). However, I would not do it at the same time as changing the API. We do not need to implement the API change right away. I suggest we finish the API change proposal acceptance process, then open a new proposal with renaming the package (or archiving the existing one and creating a new repo?) to accommodate the new accepted API.

1 Like
4

Renaming a package is also a breaking change, as package aliases don't work reliably in Xcode. So it would be good to gate it behind a major version bump anyway.

5

Yeah the “break” is both the rename, and the API changes leading to 1.0 so they need to be coordinated.

1 Like
6

Thank you for the feedback. As far as I see there is no issues left with the technical side of the proposal, it is accepted and is now Ready for Implementation.

The main feedback is we should not release a 1.0 without changing the package name to something more appropriate.

3 Likes