Jtapplecalendar: Re-implement support for cocoapods.

[p4checo]

JTAppleCalendar version ~8.0.1~ 8.0.0

Description

To avoid retain cycles, the JTACMonthView's calendarDelegate and calendarDataSource should be marked as weak, and the respective protocols should extend AnyObject to allow this.

Otherwise, anyone not using a dedicated instance as the dataSource/delegate will have to take extra care not to create a retain cycle. Since a common Cocoa pattern is for the parent view to also be the dataSource/delegate, this can become an easy mistake to make.

Steps To Reproduce

• Add a JTACMonthView to a UIView, and set this UIView as the calendarDataSource and/or calendarDelegate of the JTACMonthView.

• A retain cycle is created

Expected Behavior

• No retain cycle is created

[patchthecode]

Yes, I have made them weak in version 8.0.1

It was weak in 7.1.7
Then I made a mistake in 8.0.0 which i corrected in version 8.0.1

are you still seeing them as strong?

[p4checo]

Hi @patchthecode 🤝

Sorry, my bad 😅, I thought I had 8.0.1 since I had updated very recently. It's good to know you've fixed that on the latest version.

However, I've just tried to do a pod update, and I'm still getting 8.0.0. It appears you haven't pushed it yet to CocoaPods master repo, right?

Please let me know once you have done so.

Cheers! 🍻

[patchthecode]

ok i guess you're one of the developers who updated to 8.0.0 with cocoapods before i corrected the issue.

I have removed 8.0.0 from cocoapods because I do not want to support cocoapods from 8.0.0 and upwards. This is because Xcode 11 + now comes builtin with Swift Package Manager.

I want everyone using this lib version 8.0.0 and up to to start using SPM instead of cocoapods. SPM makes cocoapods obsolete.

[p4checo]

Well, that was unexpected 😓

Xcode 11 is still in beta, and even though I agree that SPM is the future, many apps that are in production today still don't use it because it's beta, and may take a while to migrate because it's not trivial in some cases, and in others is not even possible because SPM still doesn't support things like additional resources bundled with the packages (i.e. it's just code for now) which some projects/frameworks depend on.

We are using your framework in production and integrate via CocoaPods, and I think other projects will be under the similar scenarios. Since you're the code owner you obviously have the decision power here, but I honestly think that you are leaving out some users of your framework because it seems a bit soon to me to force this on your users.

Anyway, we'll work around this issue some other way...

[patchthecode]

Sorry if i sound like i am making a definitive conclusion.
I am very open to hear the thoughts of every one on this.

Xcode 11 will be out of beta around ~ September or so.
My thoughts on the removal of Pods were this:

1. Version 8.0 has a new feature (yearView mode) which I am still working out the kinks on.
2. Version 7.1.7 is very stable.
3. So my thoughts were to get version 8.0+ up to speed so that it will be mature by Xcode 11 public release date.

Now as to why i am dropping cocoa pod support.
I was considering removing it because I do not have an answer to this question
--> Why continue to support cocopod for this library, when developers can use SPM that comes built-in into Xcode 11?

A developer can have in his Xcode 11 project (for example)

1. Alamofire/Afnetworking cocoaPod
2. Kingfisher cocoapod
3. JTAppleCalendar SPM

They work well together within the same project. And SPM has all the advantages of cocoapods and Carthage combined. The only people that will be affected by this will be developers who _want_ to go to 8.0+ but refuse to update to Xcode 11.

What are your thoughts?

[p4checo]

My thoughts is that even though SPM is the way forward, I don't think the best approach is to "force" adoption of it by deprecating the support of still-industry-standard Carthage and CocoaPods for the new version of your framework.

I know that you can have N dependency managers at the same time (even though I think that can be messy), but why force one onto your users? That's where I'm getting at.

As for your question:

Why continue to support cocopod for this library, when developers can use SPM that comes built-in into Xcode 11?

A possible answer is that making these kind of migrations in some projects is sometimes not an easy undertaking, and there's quite some risk to it. Not all projects can or want to jump to the shiny new stuff as soon as it becomes available. And you're not even waiting for these shiny things to leave beta before deprecating currently used and battle tested tools. Isn't 8.0+ a stable release? Then why only allow its integration via a beta package manager and tooling?

Since I don't need any new feature from 8.0+, I think I'll simply downgrade and lock the version as I updated your pod because I saw there was a new version and upgraded it as a part of regular project maintenance.

[patchthecode]

Your points are valid.
Cocoapods/carthage will be re-implemented.

In the mean time stay on version 7.1.7
My understanding was that major version changes like 7 to 8 meant breaking changes. I thought it would be ok to get away with the deprecation under these breaking changes. But now I am re-considering.

Will get back to this once i get some free time this week.
Setting the enhancement flag.

[patchthecode]

Ive decided to main 2 versions.
I've just released version 7.1.8 which contains all of the fixes of version 8.0

reason? I am not good at configuring cocoapods.
Ive taken much time to try and re-implement cocoapods and SPM in the same repository. I could not get the cocoapods configured properly. If someone can help with that it would be appreciated.

So instead, I have done for the next best thing --> I'll maintain Version 7 and version 8.
New features will go into version 8, but i'll continue to do bug fixes on version 7.
I think this is a good middle ground for me given my time constraints.

[patchthecode]

Ok. As stated in wiki, this will be done once Xcode 11 fully released.
It has been release.
So Cocoapods has been re-implemented.
Latest version = 8.0.2
Closing this issue