Centralized GitHub repo for plugins

[KillerJohn]

Hi all!

I will create a GitHub repository which will basically contain the "plugins" and the "interfaces" folder from TurboHUD.

1) All plugins would go there: HUD's defaults plugin, approved plugins, and everybody's plugins
2) All non-default plugins has to be Enabled = false by default
3) Before every relese, I'll copy the latest source from that repo to my HUD repo and the release will contain ALL plugins, and I'll make sure it compiles
4) If I refactor some stuff from in the interfaces then it will be automatically refactored/adjusted in my version of the plugin repo, and when I am done, I'll merge the changes back to the public repo

This way EVERY plugin will be included in ALL releases, but in a disabled state. Users would have to enable the plugins manually.

What do you think?

[Crstina]

I think this would be a great! I just downloaded the new version of TH and none of my plugins will work.. causes TH stop working all together..

[prrovoss]

3) Before every relese, I'll copy the latest source from that repo to my HUD repo and the release will contain ALL plugins, and I'll make sure it compiles

this could be some work. otherwise its a great solution. i guess the plugin threads will still coexist with the repo? otherwise we always have to place a readme file with the plugin for instructions and configurations etc.

[SeaDragon]

People will download the latest TurboHUD release from GitHub, no longer zippyshare.com?
And include all everybody's plugins?
I'm not sure it will make me more convenient, I usually modify it after downloading people's plugins to suit myself (for example, language etc.):shh:
Now, I download the new HUD, copy my plugin folder to the new HUD folder. If there is a broken plugin, I just need to find the strings to replace them.

[MrOne]

People will download the latest TurboHUD release from GitHub, no longer zippyshare.com?
And include all everybody's plugins?
I'm not sure it will make me more convenient, I usually modify it after downloading people's plugins to suit myself (for example, language etc.):shh:
Now, I download the new HUD, copy my plugin folder to the new HUD folder. If there is a broken plugin, I just need to find the strings to replace them.

Same here, this situation can make more problems than profits, but ... we can try if you are 100% sure about that

[prrovoss]

People will download the latest TurboHUD release from GitHub, no longer zippyshare.com?
And include all everybody's plugins?
I'm not sure it will make me more convenient, I usually modify it after downloading people's plugins to suit myself (for example, language etc.):shh:
Now, I download the new HUD, copy my plugin folder to the new HUD folder. If there is a broken plugin, I just need to find the strings to replace them.

im not sure if releases will be hosted on github. but if so, it makes no difference. you just download it and dont extract the user plugins to your folder. i have no idea why this is going to be more work for you than it is now.

[KillerJohn]

- only plugins would be kept on github
- plugin devs would send in their updates via pull requests
- it is an issue if a dev is not familiar with git (imo it is complex as hell)
- HUD releases would be still on zippyshare, including the latest plugins from the repo

[KillerJohn]

also the centralized repo has another downside: plugins would be updates in 'waves' (with every HUD release)

[prrovoss]

also the centralized repo has another downside: plugins would be updates in 'waves' (with every HUD release)

how about thud performing a git pull each time it runs? this way everybody would have all plugins updated at any time.

[Firegone]

I think this would be a great! I just downloaded the new version of TH and none of my plugins will work.. causes TH stop working all together..

Would be great if it wouldn't disable itself because its "outdated" which it isn't because no patch happened and it was working a few hours ago... Now plugins stopped working...

[JackCeparou]

- only plugins would be kept on github
- plugin devs would send in their updates via pull requests
- it is an issue if a dev is not familiar with git (imo it is complex as hell)

Sorry to have to say that, but if I need to make PRs to update MY code, I'll just stop doing it.
(and I have so much stuff on my repo than include it as a sub-repo is not really possible without a massive refactoring)

[KillerJohn]

Sorry to have to say that, but if I need to make PRs to update MY code, I'll just stop doing it.
(and I have so much stuff on my repo than include it as a sub-repo is not really possible without a massive refactoring)

you could update your code in your repo (which could be a for of the central repo) and make a PR when you are done. Just like all opensource projects.

However as I said the idea has too much downsides anyways...