On Thu, 2009-02-19 at 12:14 -0800, chromatic wrote: > > Version numbers reflect elapsed calendar time, not feature set. >
Hi, As a professional configuration and release manager I have to say absolutely not. A release is established as a set of features. If you also have a time constraint then you may add or remove features as you approach your time constraint but the features are what is important. I have been watching this project for a long time hoping to someday receive a usable product and I've been continually disappointed. If you go to 1.0 with the half baked and soon to be deprecated features that you now have then you will do Parrot an immense amount of harm. I suggest put the current trunk on a branch and rip out every broken feature from the code. If what you have left doesn't work then you have your urgent work set. Also rip out every deprecated feature where the visible API is going to change. Most people will live with missing features but having to rewrite their code again and again to accommodate random API changes is going to cause your supporters to walk away. And when you do deprecate APIs you need to document the change fare better than you have been doing to date. I was developing an ANS Forth interpreter and I found I was spending more time puzzling the how and why of the Parrot changes than I was working on my own code. 8-( Cheers, Steve Gunnell _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
