In relation to my comment on updated listings, I would like to suggest a new version of jME2 be released. This has been discussed previously but seemingly with no results, and so the latest packaged release of jME 2.0 remains r4093 January, versus r4557 July or later.
Seeing as we have not been dealing with milestones to work towards it has been hard to determine what justifies a new version release, but surely with the persistent bugfixes, minor changes and a few feature enhancements accumulated over the course of six months, we can safely say jME has passed some significant milestones by now, in spite of there not being any defined.
Relevant discussions:
jME 2.1 design document
Released files
others?..
1 - Can there be an agreement on a current / shortly upcoming revision that marks jME’s next release? e.g. jME v2.0.1
2 - Is there any interest in actually setting up some milestones for a next major/final release? Possibly based off of Momoko_Fan’s design paper, but slimmed waaay down.
I also think sticking to the issue tracker would be the best way to approach this. However as for managing that change log and defining new milestones and closing existing ones, wouldn't we need at least one person specifically responsible for such task? I don't see this type of task as ideal for 'community effort' is all I'm saying.
Nightly builds should be available soon, but naturally we would still need one stable package that stays the same for about a quarters time, except minor patching. Is that what you meant by having two separate branches?
Is that what you meant by having two separate branches
pretty much yes, a branch for a stable release.
That way, if a bug needs to be fixed for a stable release, this bug can be fixed on this specific branch (and merged into trunk).
That way its easy to create new jars for this bugfixed release. (could be done automaticly from hudson)