Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Encourage forking? #573

Closed
fabiopelosin opened this issue Oct 5, 2012 · 2 comments
Closed

Encourage forking? #573

fabiopelosin opened this issue Oct 5, 2012 · 2 comments
Labels
t3:discussion These are issues that can be non-issues, and encompass best practices, or plans for the future.

Comments

@fabiopelosin
Copy link
Member

One of the special ingredients of the GitHub sauce is that it encourages forking.

We could have a common naming convection for forks so people is encouraged to publish them on CocoaPods as well. I'm thinking about something separated by a special character not commonly used but compatible with the files systems out there.

My current idea is:

POD_NAME@AUTHOR.podspec
libPusher@irrationalfab
@blakewatters
Copy link

This sounds similar to what Github used to support back in the day when they have a Gem building system before the rise of rubygems.org.

I am somewhat torn by the idea. On the one hand, it would be really nice to be able to push a forked Pod for a library in which the upstream maintainer is failing to publish an official version or merge things in a timely manner rather than having your Podfile be littered with :git => configurations pointing all over Github. On the other hand, as a maintainer of a library myself I worry about the implications of having folks being able to publish pod installable versions of RestKit to the Specs repository. The support burden can be really fierce as is without the meaning of version numbers become radically diluted… (is that RestKit v0.20.3 or SomeRandomDude-RestKit v0.20.3 you have?)

@fabiopelosin
Copy link
Member Author

In the end I think that we should not 'encourage' forks, but having the alternative is good. I any case if a fork is made for convention the above presented syntax should be used.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
t3:discussion These are issues that can be non-issues, and encompass best practices, or plans for the future.
Projects
None yet
Development

No branches or pull requests

2 participants