My opinion is that small useful components should go to core.
Also a carefully selected set of bigger high level components
should go to core to set as basis, as these will be well tested and
work well after upgrades. The alternate repository might not work with latest versions of Urho,
which is hard problem as we can’t expect individual developers to be up to date - many
prefer not to update at all.
That would either increase maintenance costs or will not be up to quality. So I really doubt there are resources (in time and hands) to do that in foreseable future. I think adding components to core is way to go
Well, for something specialized there could be something like “contrib” stuff in main repository, which is maintained like
But that doesn’t mean Urho should avoid hight-level components in core - there is basic set which is expected to have,
like IK, Ragdolls, AI components like Behavior Tree, etc. with carefully created editors and easy to use by people.
Otherwise these will have to be constantly reinvented. There is no enough high-level components in Urho.
On the one hand, putting things into Urho core helps community reuse them.
On the other hand, it will bloat Urho core.
Urho core is simple and lightweight for now. I am not about actual code size, I am mostly about generic achitecture. It has few basic blocks that could be reused in the million of differect tasks.
One we start adding things to Urho code, it will lose its elegance. It will be getting bloated… E.g. I dislike RibbonTrail. It is nice feature, but I doubt that it is as generic and reusable as e.g. StaticModel. For me it’s something that should lay as 3rdparty asset like Skybox or smth else.
Possible soluion is to put all these things into Urho3D.lib but separate them from Urho core file and class tree.
As currently things are, not including stuff with core means that the stuff is basically unusable - it will not be updated,
it will not be built. Also making people start easier with their project is much more preferred than keeping things lightweight. If you don’t use things you don’t need they are not included with your software and do not consume resources.
I like the idea too. To prevent the code rot, we could setup nightly CI (or something like that) on those components and subsystem against the current master branch of Urho3D repo. Granted that it will not verify the correctness nor the functionality provided by them, but at the very least we know immediately enough which one break and does not build cleanly. And in order not to burden the core developers, we could setup the CI build notification to be sent to the maintainer(s) of each component/subsystems directly. Maintainer that fails to perform the maintainer role can be replaced or in the event no one else could replace him/her then the component/subsystem itself could be ejected from the community repository (or being marked as DEPRECATED / ONLY WORK WITH specific old version of Urho3D).
If we really decide to do this, IMHO, the community repo should be resided in the urho3d org in GitHub. It does not only have a maximum visibility there but also technically it is easier to setup all the above when they are centralised. Note that I do not mean to say you can’t have your own components/subsystems outside if/when we have this setup in place.
I need to stress an idea that if this repository will have any chance do doverge from main Urho or have any difficulties
building it (in relation to main tree) it is not worth it. It should not become class 2 citizen in infrastructure,
so it is “still part of Urho” and separation is “for maintenance needs”. Otherwise it will become nightmare to maintain and support so it eventually die out (probably engraving some good things). So it should not be a case for “lets remove features” direction of some community members (who apparently need some kind of OSG/Ogre3D/Irrlicht to just play their shader games and do not care for much else). So that means it is a subject to bugs in issue tracker and release management.
I like the idea too, but I’m not really enthusiastic about having them in the core:
I’ve chosen Urho3D because it’s not bloated with things I don’t need or I will never use.
In my opinion, just a wiki page which lists them would work.
On the other way it would be cool to have a separate repository where can be optionally downloaded and built by using CMake options.
I’m not sure about the maintainability of the last one though.
Just want to clarify. We can have many repositories in the same “urho3d” org. So the new community repo(s), should we agree to put them there, won’t bloat the existing “urho3d/Urho3D” repo.
Perhaps it is too early to talk about having a convenience way/tool to auto download/configure the optional components/subsystems, but the idea is certainly intriguing. In my day work I use https://start.spring.io/ to quickly generate a new Java/Kotlin project. I agree with you that it will be cool if we are heading to that direction.
@weitjong I quite like the idea of adding a repository under Urho3D/Community (or maybe we’ll be able to come up with a snazzier name, something epic, like THUNDERDOME). What can I do to help get this in motion?