You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To have an idea what to work on and what to support, we need to clearly outline what we want to support. Eg we don't want to implement support/hacks for iOS or GDX (that is moving away from robovm anyway) and break all other use cases.
As a core focus (maintain + expand), I propose:
Linux
Bro with Bro generator for C
Mac OSX
Bro with Bro generator for C and ObjcC
iOS
Bro with Bro generator for C and ObjcC
Android
Bro with Bro generator for C
Available robovm tools can be used or picked up as needed. However any tools used need to be maintained so be careful what you choose.
To ensure this support we would need to have a set of code/tests/programs (we could have a look at the robovm samples?).
Initially I would not like to spend too much time expanding plugin support and just get them in a basic working state. Only when we feel confident about the state of our core (above) we can think about expanding plugin support.
Secondary focus
Eclise plugin
Intellij plugin
maven plugin
gradle plugin
Another very important facet here is scope/code ownership. We don't want everybody to wait for everybody and do everything/nothing. People should focus on what they feel comfortable with and which parts they will be using the most.
I, for myself, am mostly interested in linux usage (and I believe this to be the case for @ashleyj as well) and as such will mostly work in that area.
The text was updated successfully, but these errors were encountered:
To have an idea what to work on and what to support, we need to clearly
outline what we want to support. Eg we don't want to implement
support/hacks for iOS or GDX (that is moving away from robovm anyway) and
break all other use cases.
As a core focus (maintain + expand), I propose:
Linux
Bro with Bro generator for C
Mac OSX
Bro with Bro generator for C and ObjcC
iOS
Bro with Bro generator for C and ObjcC
Android
Bro with Bro generator for C
Available robovm tools can be used or picked up as needed. However any
tools used need to be maintained so be careful what you choose.
To ensure this support we would need to have a set of code/tests/programs
(we could have a look at the robovm samples?).
Initially I would not like to spend too much time expanding plugin support
and just get them in a basic working state. Only when we feel confident
about the state of our core (above) we can think about expanding plugin
support.
Secondary focus
Eclise plugin
Intellij plugin
maven plugin
gradle plugin
Another very important facet here is scope/code ownership. We don't want
everybody to wait for everybody and do everything/nothing. People should
focus on what they feel comfortable with and which parts they will be using
the most.
I, for myself, am mostly interested in linux usage (and I believe this to
be the case for @ashleyjhttps://github.com/ashleyj as well) and as
such will mostly work in that area.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub #6
To have an idea what to work on and what to support, we need to clearly outline what we want to support. Eg we don't want to implement support/hacks for iOS or GDX (that is moving away from robovm anyway) and break all other use cases.
As a core focus (maintain + expand), I propose:
Available robovm tools can be used or picked up as needed. However any tools used need to be maintained so be careful what you choose.
To ensure this support we would need to have a set of code/tests/programs (we could have a look at the robovm samples?).
Initially I would not like to spend too much time expanding plugin support and just get them in a basic working state. Only when we feel confident about the state of our core (above) we can think about expanding plugin support.
Secondary focus
Another very important facet here is scope/code ownership. We don't want everybody to wait for everybody and do everything/nothing. People should focus on what they feel comfortable with and which parts they will be using the most.
I, for myself, am mostly interested in linux usage (and I believe this to be the case for @ashleyj as well) and as such will mostly work in that area.
The text was updated successfully, but these errors were encountered: