The first alpha for jME3 and jMP is just days away. Upon this change I've contemplated a little about the structure and image we've currently made for ourselves regarding jME2 in contrast to jME3.
In my view, a repository is a place where one major project resides. Alongside it are branches of smaller projects; some meant to be integrated into the major project, some meant to be frequently merged into the major project. Some projects are just from-scratch experiments, created as a branch in the repository because of its strong ties to the major project.
jME3 started out as the latter; a from-scratch experiment, made to find out if whether or not a new and better 'jMonkeyEngine' could be achievable, also hoping to find that the community would gradually take an interest in this project as the spiritual successor of jME2. Now, at the brink of alpha release, the hypothesis appears valid. jMonkeyEngine 3.0 is widely accepted by the jMonkey community as the next generation of jME, and the number of collaborators is growing.
The state of things
jME3 is supported and developed by an organized team, dedicated to its progress and publicity. It is also supported by a growing community base.
jME2 is supported solely by a large community. It is maintained more so than developed, as there is no roadmap (nor need there be).
jME3 sorely needs more developer adoption for use in serious projects. With very active development, support, a stabilizing core and documentation promptly written at major milestones, jME3 is becoming the better option for production use.
jME2 is still in widespread use, including for commercial and academic purposes.
The majority of jME's showcase material as it stands is based on jME2, or some derivative of jME1. Prospective developers need to easily understand and see the differences between the old and the new, for all that it is worth.
jME2 is by all appearances the default jME branch for production development. jME2 will probably remain recommended for production use until jME 3 Stable, but already by first alpha we're gonna want to encourage early adopters as much as possible, to help steer the direction of the jME3 core and its related projects; jMonkeyPlatform in particular.
'All appearances' being: jME2 is in the GoogleCode trunk, it populates most of the wiki, it's most discussed on the forum and basically owns the 'Troubleshooting' category.
What are the suggested changes?
Move jME2 and jME3 to different repositories.
Why? jME2 and jME3 are considerably different, yet both projects are still progressing, albeit at a very different pace, and with different contributors. Keeping both in the same repository makes it very hard to keep track of one or the other. And with largely different code and separate development teams, it just does not make sense.
There are several ways of doing this:
Keep jME2 at jmonkeyengine.googlecode.com and move jME3 to some place like jmonkeyengine3.googlecode.com
Keep jME3 at jmonkeyengine.googlecode.com and move jME2 to some place like jmonkeyengine_old.googlecode.com (2 would be misleading, sounding like 'next in line')
Keep both, but move jME3 to the trunk.
Any other solution?..
For later
Separate jME2 and jME3 galleries
Targetting early-adopters
More...
This way the "old" jme2 users and branches are unharmed by this and the new jme3 users and those who switch start out in a fresh, clean and new environment As jme3 is almost completely new and is planned to be accompanied by many other tools (jMP, plugins, AI, other libs etc…) it should have its own svn to organize stuff w/o having to cope with the "old" branches etc.
I would say just switch the jme3 branch into the trunk and jme2 into a branch, so we keep the svn history. Maybe this should just be made into a poll.
Thing about a poll is that it ain't of much use until we're aware of and have discussed all our options.
I think the SVN history would remain intact regardless, wouldn't it? Can't history be transfered just like anything else? In any case, one could argue that the history being made right now becomes muddled and unclear because two projects are progressing in parallel.
For future (source-) history's (is that a paradox?..) sake, and organization too, I'm more in favor of starting a brand new jmonkeyengine3 repo. I feel a desire to see the differences between the two projects much more clearly. How often are commits made? Who make them? How many contributors are there and who are they?
It'd also be immediately clear which project the branches belong to, while now, as jMP becomes more popular, there's bound to be questions about it's jME2 compatibility.
As an update to the conversation about the subversion:
Since the Google Code page represents all of jME rather than just a single project at a time I think we should have multiple trunks under the SVN root.
It is currently set up like this:
svn/trunk (jME2)
svn/trunk/tags (jME2, jME3)
svn/trunk/branches/ (old jME2 things, 3rd party tools, jME3, Wonderland jME2, jMP, even an old jME1 folder)
This is insanity! What I would propose if we're in the mood to restructure the svn is:
svn/jme2/trunk
svn/jme3/trunk
svn/jMP/trunk (see below)
Depending on whether or not we would plan on keeping the underlying editor alive for a 'jME4' might dictate whether jMP should be under jME3, or should be its own project.
Leaving the question of where to put jMP aside this setup allows for a stricter separation of projects and a more 'normal' approach to our svn. For example, tags could now actually be expected tags rather than some from this version and some from that version thrown in there haphazardly…
Erlend and I are at a consensus that this makes sense, so we'd like some feedback from folks about getting the folder structure more in order
sbook said: Erlend and I are at a consensus that this makes sense, so we'd like some feedback from folks about getting the folder structure more in order :)
Well then, if no one is opposed, we'll simply go ahead with the change some day soon now.
As jme3 is almost completely new and is planned to be accompanied by many other tools (jMP, plugins, AI, other libs etc…) it should have its own svn to organize stuff w/o having to cope with the "old" branches etc.