Make PodsDummy class unique to each target #402
Conversation
…arget by using the Target Definition's label.
|
Awesome. Thanks! Would you like push access? |
Make PodsDummy class unique to each target
|
Thanks for merging it. Regarding pull requests, what would that entail, specifically for code reviews? Since I'm not a regular contributor I think code reviews for significant changes are appropriate. |
Small changes, like doc changes, can be pushed directly. Having push access lowers the barrier for such ‘simple’ yet very important changes. For significant changes you can still use a pull-request to discuss, but after having discussed it and you possibly making suggested changes to the patch, there comes a point where the response will be: “after you change X the patch is good and can be merged”, having push access means that we don’t have to yet again spend time on it, because you can then merge it yourself. The choice is really up to you, we simply have a ‘1-patch for commit bit’ policy, which is why I asked. One important warning is that you would get a lot more emails from GitHub (if you didn’t disable email notifications), because GitHub doesn’t yet allow you to disable notifications for ‘organisations’. |
|
Thanks for the explanation. I like that approach and would like push access. Thanks for warning on the emails - I recently received push access for the Specs repo and have experienced the many emails. |
|
@dlvenable Done, welcome! :) |
added podspec for JBKenBurnsView
Make PodsDummy class unique to each target
The PodsDummy class can cause linker errors when using a static library project and a unit test. I changed the installer to create unique PodsDummy classes using the label provided by TargetDefinition.
This should fix:
#342
#370