Since the current 2.0 source seems pretty stable, maybe it would be a good idea to tag it and make jars available for download on the goggle project page.
That way people can just grab the jars, and won't need to create them themselves.
Or is there no need for it ?
Once the current source is tagged (or branched) as stable, its more safe to add new features which might introduce new bugs.
+1
I agree.
I would also think of tagging it as "2.0 beta" or something similar.
I also agree, jars are very convenient to use 
It can't hurt. I say do it.
I think Beta would be a bit to early, beta would mean its ready for testing and usually includes more or less all features.
But hopefully, jme2.x will receive still quite a few new features, sometime…someday…eventually
Oh yeah, agreed. Just meant that it is not a final version. 2.0 is proibably fine anyway :).
so who's gonna do it?
and how will the tag be named?
the last cvs tag names were:
pre09
prelwjgl09
v011
v09
v10
v1_0
so i guess v20 would make sense or alpha20 or 2.0 alpha?
v2_0
I was thinking of just creating a tag, no branch.
The idea behind the tag is just to mark the created jars, with the current svn revision.
So if someone downloads the jars and encounters a problem, we can tell exactly what source he got.
There won't be any fixes done on the tag.
In this case, a tag is not needed. Take the revision number as a reference. Mark the binaries as compiled from revision r4050
The name could be: jme2.0alpha-r4050.zip
hmm good point thats much less hassle, and the jars can easily be updated.
it seems i'm not allowed to create new downloads 
i guess a project owner needs to do this.
After branching, all fixes for 2.0 have to be merged with trunk. I hope everybody contributing is familiar with the concept of merging.
Any input from a developer ?
If no one has anything against it, and if i'm allowed to, i go ahead and:
- create the tag v2_0
- make jars, zip em and make them downloadable
If we're about to start putting out releases is there any reason why there are so many jar files generated by the build process? I can see that some of them are quite large and that it may well make sense to keep them separate because of this, but surely we can get by with less that 13 jar files!
I'd like to suggest the following packaging
- jme-core.jar: the existing jme core library;
- jme-extras.jar: combining most of the other packages, except;
- jme-imp-exp.jat: all of th import export code (i.e. collada, model, and xml); and
- jme-effects.jar: same as it is now.
Oh, and maybe jme-examples.jar, with the demos that aren't currently bundled.
I think that this will also make it easier to make the jars into OSGi bundles as well (note that I'm not suggesting adding OSGi code to JME, just the couple of extra lines in MANIFEST.MF that OSGi requires).
thoughts?
For the name how about jme-snapshot-r4075 ? This seems to be a quite common naming scheme amongst open source projects.