Brave new (1.0) world.

[Stephen Gunnell]

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