As Nike says: Just Do It!
There have been countless situations in the tech industry where a company releases a nearly finished/final application/api as the dot zero version and then deals with the aftermath and calls the outcome of that the dot one version.
I'm all for the countdown method using a three-month timeframe… and maybe having such a deadline in the future will light the fire to actually make this happen. And, if we shoot for say end of Q1 2009 and have a spring release/cutover to 2.0… we can even tag it with a distro name like "jME 2.0 Pro Version" ; - )
basixs said:
Basically because it's not final?
Yes, Final and stable are words which appeal to budget holders.
Well I personally don't care about budget holders. Pretty much any software in the open source is not final (e.g Apache), it's not a bad thing that there are always fixes and new features.
Thing is, as a developer (as opposed to one of us who is also concerned about the wellbeing of JME for it's own sake), you don't care about all the bugs in the engine. You only care about bugs that affect your own code.
If you have tested your code thoroughly, then you know of any bugs that you need to fix. If the engine then changes underneath you then you do not, until you have retested.
Therefore updating the JME version carries a risk - not that there will be a higher total engine bug count, but that you will have to start testing again from scratch or live with the possibility that there are unknown problems with your code. This risk is made greater by the fact that potentially many more people are now making changes.
If you know that a repository will only be updated with bugfixes or code that has been tested then your risk is less. Since JME2 is by all accounts fairly stable and used by most users, it should not be presented as unstable, and there should be a stable release.
I may be speaking a little out of turn here as I am a JME novice and have only dabbled with 2.0 (just wish I had more spare time to spend experimenting with it) but I am a developer of over 20 years experience and a jaded view of "seen it all before" 
Firstly JME isn't a commercial engine and I think its wrong to try and treat it as such by constantly supporting older versions. JME's target audience (at least for now) isn't professional organisations as much as it is hobbyist coders.
Please don't get me wrong here - I really am not trying to belittle the efforts that have gone into JME and the results that have been achieved and I appreciate the desire and need for stability. The problem here is that the QA team for JME is its users, and although nobody is currently forcing anyone to move to a newer version, the engine as a whole needs people to do just that. By not fixing issues in older versions but only in the latest code, you promote a forwards progression which is good for everyone in the long run in that by updating your code to work with the latest version you may find new bugs etc and end up giving something back to JME by providing the QA and at least logging the problems if not fixing them.
I totally agree that the desire is not to have to spend time fixing JME when you want to be working on your own project, but I also think that when using any open source library you have to expect problems. So you work through them and hopefully give something back - whether its a fix or just logging the bug so someone else can review and fix it -you aren't the only end user, and as a community every little fix helps. I have always been a firm believer that you should understand at least some of the inner workings of anything you use else how can you know when a problem is you or the library, and lets face it - game development is a hell of a lot more complicated than writing some generic webapp!
With regard to "professional organisations"; there are things far more likely to put them off than the latest version being beta type code. Examples include the lack of fulltime professional support, any kind of feature list or timeline for extra/new functionality or fixes, change logs and in particular any obvious way to log and track bugs (how many users here actually know or use the issues tracking on google code?, and posting to a forum is not really considered an acceptable solution for defect tracking) - these being the foremost in my mind. Maybe I just haven't found them (I only found out about the google code issues list today because of a post on the forum mentioned it) but if they are that well hidden it doesn't help either.
I may be biassed here as I work for a company which has stupidly got itself into the mess of supporting 6 different versions of the same product, and often have to fix something in an old version then make the same fix into all the other branches, arrange for them all to be tested etc etc. Its a right royal PItA - often this will take so much time due to working with other changes that it became an incentive NOT to fix something if you could get away with it, or just log it and hope someone else gets given it :( Then we have the nightmare of backfitting fixes (or even new features - ugh) . . . but enough of my employers incompetence 
In summary, don't support JME1.0 and look to the future.
<< JOC >>
sorry for the essay
Is anyone opposed, hopefully with a valid argument, to putting a date as to when we archive 1.0?
(2-3 months seems more than ample to me…)
basixs said:
Is anyone opposed, hopefully with a valid argument, to putting a date as to when we archive 1.0?
What is your definition of archiving 1.0?
I don't think anything really needs to be done with 1.0. What we really need to do is tidy up a few things in 2.0 (like finishing the enums) and getting that tagged and put up. As far as 1.0 is concerned, I think few changes on the download page and in the wiki that move it towards the background and lift up 2.0 is all we need. Just shift the attention.
Whats really important is that there are downloadable jars and sources, so that people without access to svn (because of firewalls who block the traffic and such) can get the jars. This got requested quite a few times already.
On the download page it should be mentioned cleary that:
- jme2 is the recommended version, but its api can and will change, as it is under development.
-jme1 is the 'old' feature-frozen version, which wont be bugfixed anymore (it could still receive bugfixes, but i think no one who has access to the cvs has time to do that).
When thats done, the wiki's jme1 code should be converted to jme2 and then linked from the jme2 part of the wiki.
The jme1 part of the wiki is then whats slowly gets archived.
Yes, I'm in agreement.
To me archiving, is keeping something: unchanged, secure, and available upon need, putting it into a (possible compressed) single file or removing it from the old SVN would break the 3rd rule (it wouldn't be very available) 
And in this instance keeping it completely un-changeable is actually something we want to avoid (the ability to apply needed bugfixes is almost a 'guarantee' to any potential decision makers evaluating jME).
I don't think we want to to get rid of jME 1.0 completely or even to stop people from getting it, simply to move the focus to 2.0; so I think we are in agreement here…
What we really need to do is tidy up a few things in 2.0 (like finishing the enums) and getting that tagged and put up.
From the general consensus it seems people would like this done before 'archiving' 1.0, do we have a more detail list of what is required to 'finish' up 2.0? (I don't think any new features should be added to this, unless they are an integral part of 2.0...)
And do you think we should branch the current version, and then deploy all the new changes at once when the are finished? Or make gradual changes to the existing 2.0 codebase?
If everybody agrees, then jME2 now becomes the mainstream version.
The appointed project managers should create jars for the latest CVS/SVN versions of jME1/jME2 and put them on the googlecode and java.net pages.
This page may need to be updated:
http://www.jmonkeyengine.com/wiki/doku.php?id=download
Also, make sure the latest jME2 javadocs are available here:
http://www.jmonkeyengine.com/doc/
Whatever you do with JME 1.0 and JME 2.0 will have a profound effect on how people use it in the future, so be very careful.
I am running a commercial project that starts in a couple of days for a big project for which we are planning to use JME for the main user interface. This will be several months of development for a reasonable sized team of experienced JME developers. The big question at the moment is do we use JME 1.0 or 2.0.
Now if 1.0 is locked down and not going to change then commercially it is the best option as developing against a changing implementation is not viable. However if you decide to completely remove JME 1.0 or make it inaccessible then it is not a viable option either.
So the question is do you want JME to be more than a hobbyist curiosity? If you do then what you do with JME 1.0 is a critical decision - get it wrong and in the words of a certain ex CEO you "kill the baby".
jarec said:
However if you decide to completely remove JME 1.0 or make it inaccessible then it is not a viable option either
jme1 will always be as accessible as it is now.
Nobody is gonna remove the cvs or the available jars, but none of the contributors have access to the cvs to fix bugs either.
So, if you encounter some bugs which needs to be fixed, you would have to deal with them yourself.
So, if you encounter some bugs which needs to be fixed, you would have to deal with them yourself.
I would hope one of the 'old grizzlies' would still care enough for jME to apply any needed bugfixes to 1.0...
jarec said:
Now if 1.0 is locked down and not going to change then commercially it is the best option as developing against a changing implementation is not viable. However if you decide to completely remove JME 1.0 or make it inaccessible then it is not a viable option either.
1.0 will be phased out eventually, but a roadmap is needed to allow transition for projects on older version to migrate. This is more than a 1.0 issue, its more so a professional practice.
IMHO 2.0 should be locked, only applying bugfixes and 2.1 or even 3.0 should be opened for feature enhancement. Perhaps follow the way Sun version java would be a good approach.