@dreampiggy glad to see you are working on this project of separating MapKit into its own repo.
I think it's a good idea, I wanted to do it a few times, but there were always more pressing issues :)

My only concern is we are breaking compatibility, since people that have the 5.5 version will need to make changed to their Podfile in order to keep having the MapKit module.
I think a better approach is to release this change with a major version upgrade (i.e. 6.0) and therefore make it clear that this breaks the compatibility (even if a large number of our users are not using the MapKit integration, it's still the right way to do it according to the semver standard).

@SDWebImage/collaborators what do you think?

Actually...In 6.0.0 I have a bigger idea changes, which I want to have a better support for Swift user. The contributor who are famailiar with Objective-C is really hard to find, move to Swift (through it's just a wrapper layer) can make it easy to maintain...

Therefore I think we can refactory our architecture with a Swift-written overlay layer (This SDWebImage become the Objc-Swift mixed framework). This is a major change.

I doubt the break area for users. Because most user basically not integrate MapKit. I do not have a accurate survey, but we can get it through whole GitHub search with Podfile/Podfile.lock.

See:

• Use SDWebImage/Core (not with default subspec): https://github.com/search?utf8=%E2%9C%93&q=SDWebImage%2FCore+filename%3APodfile.lock&type=Code&ref=advsearch&l=&l=

• Use SDWebImage/MapKit: https://github.com/search?utf8=%E2%9C%93&q=SDWebImage%2FMapKit+filename%3APodfile.lock&type=Code&ref=advsearch&l=&l=

And, what is SDWebImage/Main, did SDWebImage contains any other subspecs in history ?

@dreampiggy the stats you provided are from open source projects. There are many more closed source projects that are using SDWebImage.
I don't think we can make the decision based on how many people may or may not be using that submodule. We started years ago to follow the semver standard because it has a clear intent of what changes were made in a version and I don't want to bypass it.
Plus, I don't really see why we can't release the MapKit removal in a 6.0 version and make all the Swift changes you are referring to in another major version 7.0.

Looking forward to hearing more opinions here, cause I'm not married to my opinion :) and therefore I don't want to force it if more people are against it.

Maybe you're right. Actually I don't want to release next major version because currently, seems there are no huge maintain with the exist APIs...The 6.0.0 changes seems source-code compatible for most cases, but all the downstream dependency who use s.dependency 'SDWebImage', '~> 5.0' need to bump the version... The pay seems more than what they gain. :(

I'll try to find another SwiftPM DSL, hopelly that can workaround Apple's bug. As the comment in #2941 , seems this effect all the Objective-C project contains 2 or more target...I doubt why so huge bug Apple team does not realize. :)

Codecov Report

Merging #2946 into master will decrease coverage by 0.25%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #2946      +/-   ##
==========================================
- Coverage   83.88%   83.62%   -0.26%     
==========================================
  Files          69       66       -3     
  Lines        7105     6444     -661     
==========================================
- Hits         5960     5389     -571     
+ Misses       1145     1055      -90     

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update aa7ff6f...5287e0d. Read the comment docs.

This pull request has been automatically marked as stale because it has not had
recent activity. It will be closed if no further activity occurs.
If this is still applicable, please make sure it is up to date and if so,
add a comment that this is still an issue to keep it open.
Thank you for your contributions.