Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (757)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (844)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  A Xith fix / enhancement process dialog  (Read 2135 times)
0 Members and 1 Guest are viewing this topic.
Offline hawkwind

Junior Devvie

Java games rock!

« Posted 2006-09-02 02:46:42 »


     It is pretty obvious the we are in a place many other net based groups have faced...where are we going and how do we get there??  Group governace of something like Xith is difficult, perhaps a small set of...err...guidelines..might be able to establish a process we can all agree to to some degree.I have been thinking on this and have a few ideas to toss around in no particular order.

o  Sub projects that are actively maintained by the original author, required the authros input before another user makes API breaking mods or radically  alters behavior.  This is between the author and who ever in making upgrades...I am thinking of the recent HIAL mods that involded William...very nice collaboration here...three cheers!!!

o If a user wishes to modify a sub project and cannot find or get the original author to particpate, they should propose changing it without authorization.  While I strongly hold to the concept that authorship is deserving of great praise and respect, at the same time I feel if I have written something, and I don't plan on improving/fixing it, I lose my rights to veto changes after some acceptable time frame.  Similar to posting estate information in a newspaper...people have N days to make a claim on assets, if thay fail to do so they lose out..  People come and go in these situations, current participation weighs more than older participation in my books

o Major API changes should be described in a small proposal, open for discussion for a week or two.  People vote with their comments...if you fail to vote for your elected leaders you cannot complain about your taxes.!!  If a resolution can be achieved a release can be rolled for people you wish to stay with previous API's .  The power of individual votes is up for interpretation, some people are very active and maybe should have heavier weighting on their vote, other haver professional vested interest (Croft!!) in stability...this deserves a heavy vote also.

O Major API changes need to be inserted along with at least a verbal commitment that you rebuilt and tested the demo programs.  After years of programming I am still amazed at the sublte surprises I have coded into my fixes.

o Major API changes  need to be demonstrated in a new example or a modified demo...absolute requirement..prove your changes actually work..

o MyFavoriteFunctionVersion10298 is just a rediculus naming scheme, If something has been significantly modified then the two rules above validate the work and now our examples all point to the more current work  (thinking of textureloader versioning)

o  I like depracated functions to identify older non supported stuff....I am not sure if this works with small changing development groups with only occasional releases..  I would prefer to update things to the newer version and drop old versions, since the API changes were proposed and discussed an ealier posting then there will be a general feel if anyone is going to be advesly affected before the changes occur.

Just some thought...your milege may vary  Tongue

Offline Marvin Fröhlich

Senior Devvie

May the 4th, be with you...

« Reply #1 - Posted 2006-09-02 10:03:43 »

hmm... I totally agree with you.

But all this is already practiced. Except for the question, what to do with deprecated/dropped stuff. The SchreensotEngine stuff for an example. I've moved the methods and marked the old ones depreceted. Or the whole Canvas3D class which was totally misplaced in the scenegraph package and which I've moved into the render package and placed a Canvas3D class extending the original com.xith3d.render.Canvas3D into com.xith3d.render. This way the code is still backwards compatible and the deprecated com.xith3d.scenegraph.Canvas3D class can be removed in the future. The disadvantage is that we'll have several duplicated classes, if we do it with more classes. But I think it will be necessary to have a clean API. I think we need to break the API once in a whole and provide a plan for people to get an easy upgrading process. e.g. the old com.xith3d package structure should renamed into org.xith3d. First of all this is the correct naming for the package(s) and this way we'll have the change to move things from the tk to the core (or vise versa) without braking the API. The toolkit could additionally serve as some kind of beta platform and when things have proved they can flawlessly moved to the core.

And I've written about a development plan just yesterday. I'll make and release it at the end of the comming week.

Even if there's nothing new in you posting, it's nice to hear, that we're pulling on the same string. Wink

Offline Amos Wenger

Senior Devvie

Everything's possible, but not everything's fun...

« Reply #2 - Posted 2006-09-02 19:06:30 »

I do agree with you hawkwind on all your points. Now there's just some things that you're assuming in your talk :
- Xith users *have* to be on the forum
- Everyone (no matter who) can come and begin to lead Xith3D

The thing that bothered me for a long time with Xith3D is : how far can I go ? To code things in supplement of the original codebase is not a problem for any open-source project but things like major API changes and things like that worry me more.. What can and can't we do ? Can we do anything as long as they're no major complain ?

Marvin, I'm waiting your development plan with impatience  Grin

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Pages: [1]
  ignore  |  Print  

EgonOlsen (59 views)
2018-06-10 19:43:48

EgonOlsen (41 views)
2018-06-10 19:43:44

EgonOlsen (61 views)
2018-06-10 19:43:20

DesertCoockie (240 views)
2018-05-13 18:23:11

nelsongames (142 views)
2018-04-24 18:15:36

nelsongames (141 views)
2018-04-24 18:14:32

ivj94 (883 views)
2018-03-24 14:47:39

ivj94 (144 views)
2018-03-24 14:46:31

ivj94 (795 views)
2018-03-24 14:43:53

Solater (159 views)
2018-03-17 05:04:08
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!