SDWebImage 5.0.0 release checklist

[bpoplauschi]

This is supposed to help us track the remaining things for 5.0.0 release.

5.0.0-beta release checklist

• [x] simulate a merge from 5.x to master to see what the overall changes are
• [x] review and improve naming across the project - #2291
• [x] check public entities that could be moved to dedicated files (i.e. SDWebImageCombinedOperation)
• [x] review all the entities we now have in the 5.x branch and see if any should be moved to a dedicated project (like a coder or something else). We should keep this project minimal.
• [x] #define LOCK(lock) ... and #define UNLOCK(lock) ... should not be duplicated in each file where they are used - done in f8fe886
• [x] update docs
  
  
  
  • [x] update readme on the support for animated images and examples
  
  
• [x] update CHANGELOG.md and add SDWebImage-5.0-Migration-guide.md #2275
• [x] review open issues/prs with no milestone
• [x] remove FLAnimatedImage support entirely #2385
• [x] publish 5.0.0-beta1

5.0.0-beta2 release checklist

• [x] Add SDImageCoderWebImageContext coder option, which allow custom coder plugin, to receive the context option from top-level API #2405
• [x] Updated all existing diagrams for 5.0 release + added new ones (small detailed diagrams for the most important components) #2407
• [x] Change SDImageFormat to use NS_TYPED_EXTENSIBLE_ENUM instead of fixed enum, to allow custom coder plugins to extend it #2400
• [x] publish 5.0.0-beta2

5.0.0-beta3 release checklist

• [x] Feature disk cache migration from 4.x #2417 #2433
• [x] Add default HTTP User-Agent for specific system #2409
• [x] Improved unit tests #2438 #2434
• [x] Adopt all the protocol APIs which contains getter value to use property instead, to make the API easy to use or Swift user #2452
• [x] Remove sd_setAnimationImagesWithURLs API, because its cause ambiguity, behave not consistently and have rare use case #2459
• [x] Extra args for SDSetImageBlock (added cacheType and imageURL) #2449
• [x] publish 5.0.0-beta3

5.0.0-beta4 release checklist

• [x] move webp component to dedicated project SDWebImage/SDWebImageWebPCoder #2469
• [x] Carthage improvements: no libwebp and FLAnimatedImage dependencies + offer 2 targets (SDWebImage and SDWebImageMapKit) to people can choose which one to install #2476
• [x] fix Progressive decoding (for large images) runs too frequently #2477 - solutions #2478 #2479 or #2480
• [x] another review of the README, CHANGELOG, MIGRATION GUIDE to 5.x docs per latest 5.x changes #2388

5.0.0-beta5 relase checklist

• [x] Fix encoding options does not works #2602
• [x] Remove unnecessary CGImage check when encode first frame #2609

5.0.0-beta6 release checklist

• [x] Fix the issue that SDWebImagePrefetch in 5.x, will submit all prefetch URLs to manager without any concurrent limit #2631
• [x] Fix the current transformer cache key generating rules, try to keep the image file extension #2635
• [x] Move some internal classes into private header files, make it easy to maintain the code #2634

5.0.0 official release checklist

• [x] give the beta(s) some time for feedback gathering. Ask some users to try it out.
• [x] update the API diff based on the latest 4.x release (4.4.6) and the last 5.0 commit
• [x] update the API documentation and add link on the Wiki page: https://sdwebimage.github.io/
• [x] update the migration guide for 5.0, with the latest information, update url link from 5.x to master
• [x] update the full changelog for 5.0
• [x] check out current master branch into a seperated 4.x branch, for keeping a short term maintain for serious bug
• [x] merge the 5.x branch into the master (due to PR issue, we now using 5.0 branch), See #2664
• [x] release the 5.0.0 for CoaoaPods and Carthage

5.0.0 related coders/plugins repo upgrade

• [x] [SDWebImageWebPCoder](https://github.com/SDWebImage/SDWebImageWebPCoder) Release v0.2.0
• [x] [SDWebImageHEIFCoder](https://github.com/SDWebImage/SDWebImageHEIFCoder) Release v0.5.0
• [x] [SDWebImageBPGCoder](https://github.com/SDWebImage/SDWebImageBPGCoder) Release 0.6.0
• [x] [SDWebImageFLIFCoder](https://github.com/SDWebImage/SDWebImageFLIFCoder) Release v0.3.0
• [x] [SDWebImageSVGCoder](https://github.com/SDWebImage/SDWebImageSVGCoder) Release v0.2.0
• [x] [SDWebImagePDFCoder](https://github.com/SDWebImage/SDWebImagePDFCoder) Release v0.2.0
• [x] [SDWebImageFLPlugin](https://github.com/SDWebImage/SDWebImageFLPlugin) Release v0.3.0
• [x] [SDWebImageYYPlugin](https://github.com/SDWebImage/SDWebImageYYPlugin) Release v0.2.0
• [x] [SDWebImagePhotosPlugin](https://github.com/SDWebImage/SDWebImagePhotosPlugin) Release v0.2.0
• [x] [SDWebImageProgressiveJPEGDemo](https://github.com/SDWebImage/SDWebImageProgressiveJPEGDemo) Update the dependency and Readme
• [x] [SDWebImageAPNGCoder](https://github.com/SDWebImage/SDWebImageAPNGCoder) Deprecated, 5.0.0 built-in class. Need update Readme

5.0.0 downstream partner adapting

• [x] [FirebaseUI](https://github.com/firebase/FirebaseUI-iOS) Support Custom Loader feature. https://github.com/firebase/FirebaseUI-iOS/pull/654 Will release v7.0.0
• [x] [React Native FastImage](https://github.com/DylanVann/react-native-fast-image) Support Animated Image instead of FL. https://github.com/DylanVann/react-native-fast-image/pull/454 Released v6.0.0

[Panajev]

So exciting :).

Sent from my iPhone

On 16 Apr 2018, at 08:28, Bogdan Poplauschi [e-mail] wrote:

This is supposed to help us track the remaining things for 5.0.0 release:

simulate a merge from 5.x to master to see what the overall changes are
review naming across the project and see where we can improve/simplify
should we keep using SDWebImage as prefix? for me it's too long
update docs
update readme on the support for animated images and examples
update CHANGELOG.md
SDWebImage-5.0-Migration-guide.md
update the diagrams
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[bpoplauschi]

@dreampiggy what's the order we should review&merge the remaining open PR's?

[dreampiggy]

Maybe from the small changes to the large changes ?
I recommend the order to be #2280 -> #2282 -> #2278 -> #2256.

That #2265 is not a API break change, just a project enhancement feature, which may contains only directory level arrangement and may cause many conflict if been merged first. So should be processed in the last..

[bpoplauschi]

Good plan @dreampiggy. I have already reviewed and merged #2280 and #2282. I'm looking into the other PR's, please let me know if you need to update anything on those.

[bpoplauschi]

@dreampiggy regarding FLAnimatedImage, can you take care of removing this dependency from our code and moving your FLPlugin project to the SDWebImage org? Then we can reference it properly and get rid of FLAnimatedImage for good.
Or I can do the removal, just let me know how you prefer.

[dreampiggy]

I'll transfer that repo to SDWebImage organization soon, and move current all code to that repo and get dependency update (It's midnight in my timezone, I'll do this hours later :))

[bpoplauschi]

Quick question: SDImageAPNGCoder is now inside the repo. Should we just keep this in it's dedicated repo and remove it from the main project?

[dreampiggy]

@bpoplauschi Deprecated is enough. And I will update it to add one dependency, to avoid SDWebImage 5.x user accidentally import that:

s.dependency 'SDWebImage', '< 5.0'

[bpoplauschi]

@dreampiggy @skyline75489 @mythodeia @zhongwuzw I've just released 5.0.0-beta.
We should try it out, also ask other people to do so.

[dreampiggy]

@bpoplauschi So fast. I'll check and collect the issue for 5.x beta version later.

The 4.x branch still need something change to be maintained, until the final 5.0 release.

[bpoplauschi]

Cool. I've cleaned up the 3.0-compat and 4.x branches - no longer needed. We will keep using master for the 4.x releases - probably 4.4.2 until 5.0 is ready to be released (released and merged into master).

[bpoplauschi]

@dreampiggy @mythodeia @skyline75489 @zhongwuzw can we all test a bit the beta release? Any other people you want to involve for beta testing? Like people you talked to on GitHub and are interested in our project

[dreampiggy]

@bpoplauschi I can try 5.0.0-beta later in my small App later. And try to find the issues in 5.x.

[bpoplauschi]

@dreampiggy I did try this version in a very simple project. Works fine. We can still rely on our unit tests for another point of view of testing. But maybe we need to update/add more tests, as it seems with 5.x we are around 65% coverage, as for 4.x we had 75%.

[dreampiggy]

@bpoplauschi The unit test drop, based of previous 4.x test coverage is wrong. It contains the Test code itself, they should be ignored. The actual coverage should become nearly 70%.

5.x introduce many feature, I try to add many test for the big features like Animated Image, Image Transformer and customization. But however, some test which relay on the UI-test like image indicator is hard to test, but I can try to add about it soon.

[bpoplauschi]

@dreampiggy I see. Good to know about the Test being included in the numbers. That was misleading and I do remember we talked about this :)
Anyway, don't worry, we will improve the tests all together. You did a good job adding tests for the features added in 5.x.

[itdongbaojun]

libwebp to 1.0.0

[bpoplauschi]

Agree @itdongbaojun - we will bump the dependency to libwebp 1.0.0. We are still looking into perhaps moving the libwebp coder to it's dedicated repo, like all the other custom coders.

[bpoplauschi]

SDWebImage/SDWebImageWebPCoder already works with libwebp 1.0

[dreampiggy]

@bpoplauschi What about the state now ?

Should we still wait for @rs to transfer the repo to SDWebImage organization ?

Or we can first release 5.0.0, later do a transfer. GitHub will automcatilly redirect the URL or git repo to from the old one to the new one. And seems changing the source in the Podspec or Carthage files does not cause any API breaking to effect semversion.

[rs]

About the transfer, I got no replies from you guys in the email thread.

[dreampiggy]

@rs I'm sorry. Maybe I misunderstand the meanning of that last mail ? I think we've already end up a consolution that we'll follow these thing. So I'm wondering if that you're busy recently so didn't reply to the final email.

• the license will remain MIT, I think it's the best license for open source and we will stick to it
• we have preserved the copyright (if no mistake slipped in any of the files) and we will continue to use this one
• your name is the only name in the Author section, as you are the creator. We are just Collaborators. Let's keep that as well
• I have made you owner of the SDWebImage organization - I thought you were already, sorry, my bad
• I think all the people on this email can commit to keeping clear your role as author

Anyway, I reply it with email now.

[dreampiggy]

@zhongwuzw Any extra idea about these things above, to transfer this repo into our SDWebImage organization ?

[zhongwuzw]

@dreampiggy 👍 Good to see it! and I think we can add rs to the Author section in all projects in SDWebImage organization. All of them benefit from SD.

[bpoplauschi]

About the transfer, I got no replies from you guys in the email thread.

@rs we have sent a number of email, on both your dailymotion.com and rhapsodyk.net accounts. I didn't paste the entire address here. Please let us know how to proceed. We are pretty much blocked at this point

[rs]

I was expecting a reply to my last email. Please stop using my dailymotion email.

[bpoplauschi]

@rs I just sent another email to the account you prefer. Please note we are waiting for a resolution of the repo transfer so we can make the final push for the 5.0 release.

[rs]

Transfer done.

[bpoplauschi]

Much appreciated @rs

[dreampiggy]

@IljaDaderko Seems a strange behavior from my mind. Could you please open a issue about this, provide a demo project or code to show the issue and let me investigate ? This issue is about 5.0.0 release check list used by the contributors.

[IljaDaderko]

@dreampiggy I resolved it by cleaning build folder, must've been something weird there.

[dreampiggy]

• update the API diff based on the latest 4.x release (4.4.6) and the last 5.0 commit
• update the migration guide for 5.0, with the latest information, update url link from 5.x to master
  Done via 36e89af

[dreampiggy]

• update the full changelog for 5.0
  The change log (draft) is below:

[dreampiggy]

5.0.0 Major release - Customizable SDWebImage, on Mar 31th, 2019

See all tickets marked for the 5.0.0 release

Features

Animated Image

• Introduce SDAnimatedImageView and SDAnimatedImage for full stack solution of animated images.
• Supports custom coders for nearly every animated image format.
• Supports progressive loading for animated images.
• iOS/tvOS/macOS cross-platform support.

Transformer

• Using transformer to apply image processing after image was loaded.
• Built-in transformer for common usage: Rounded Corner, Resize, Crop, Flip, Rotate, Tint Color, Blur Effect, Core Image Filter...
• Convenient category methods for UIImage/NSImage

Custom Loader

• Using loader protocol to implements your own image loader.
• Not limited on HTTP, you can even using SDWebImage with PhotoKit and third-party SDKs.
• Supports multiple loaders at the same time using SDImageLoadersManager.

Custom Cache

• Using cache protocol to implements your own image cache.
• Standalone disk cache and memory cache class for advanced usage and customization.
• Supports multiple caches at the same time using SDImageCachesManager.

Indicator

• Use indicator to provide a loading view, customizable
• Built-in Activity Indicator and Progress Indicator.
• iOS/tvOS/macOS cross-platform support.

Plugins

• All external image format coders are plugins. Supports WebP, HEIF, BPG, FLIF, SVG, PDF... Choose what you need in: Coder Plugin List
• PhotoKit loader as a plugin: SDWebImagePhotosPlugin
• FLAnimatedImage integration as a plugin: SDWebImageFLPlugin
• YYImage/YYCache integration as a plugin: SDWebImageYYPlugin

Improvements

Swift

• Better Swift support with some manual renaming APIs.
• Full nullability annotation.
• Using class property for shared instance.
• Using NS_TYPED_ENUM and NS_STRING_ENUM for better generated APIs.

API

• Using context option to control detail behavior for each image request beyond the limit of enum.
• Using prefetcher to manage token (list of URL requests) to avoid conflict.
• Use request modifier to modify constructed URLRequest.

Project

• Supports the latest Xcode 10.
• Supports iOS 8.0+/tvOS 9.0+/watchOS 2.0+/macOS 10.10+.

Migration

Check 5.0 migration guide for the migration from 4.x to 5.x.

[dreampiggy]

• check out current master branch into a seperated 4.x branch, for keeping a short term maintain for serious bug
  Done.

[dreampiggy]

• merge the 5.x branch into the master

This step failed. Did anyway can provide a help to create a PR ?

When I click Create pull request button, GitHub showing the error

Pull request creation failed. Validation failed: A pull request already exists for SDWebImage:5.x.

Any help for this ? @bpoplauschi Could you also have a try (Since you're in admin level permission)

[dreampiggy]

• merge the 5.x branch into the master
  I've already merge the 5.0 branch into master. Ready for update the changelog.md and release.

[dreampiggy]

• release the 5.0.0 for CoaoaPods and Carthage

The 5.0.0 version is tagged and been released!
See changelog: https://github.com/SDWebImage/SDWebImage/releases/tag/5.0.0

The CocoaPods spec file have already been uploaded as well

[dreampiggy]

• 5.0.0 related coders/plugins repo upgrade

Done 5 of all.
I'll upgrade the remained coder plugins tommorow. Since it's midnight in my local timezone now... 😪

---

Done all of them.

[bpoplauschi]

Appreciate your efforts @dreampiggy

[dreampiggy]

Update

The newest status of SDWebImage 5.0 for downstream dependency adaptation.

• React Native Fast Image:
  Released v6.0.0, which use SDWebImage 5.0 and SDAnimatedImageView instead of FLAnimatedImage for animation rendering.

• FirebaseUI
  Will release v7.0.0 after Google/IO 2019, which use SDWebImage 5.0 with Image Loader API for better integration.

[bpoplauschi]

Very nice @dreampiggy.
Should we close this issue now that the 5.0 release is fully out?

[dreampiggy]

I've close this issue. Since all the milestone for 5.0.0 is now done. Le'ts looking forward for future plan and milestones