I get your point and generally in most of your posts you try to say that 'done' is basically that needs to applied to unsupported software. But that is not what the debate is about. The debate is about a specification and a implementation that matches the specification, Neither of which is complete. What I mean to say is add as much as water you wish to add to a pool but when you want to walk on it, just freeze it. In the next cycle add some more water..freeze.. and the cycle goes on.
Re^6: The current state of Perl 6
Replies are listed 'Best First'.
The debate is about a specification and a implementation that matches the specification....
Royce's 1970 paper itself debunked that idea, no matter how many people have misread (or, more likely, misNOTread) it over the past 40 years. I suppose it's grown into its own cottage industry, much like misquoting Fred Brooks out of context.
Well nobody is saying that the specification should be frozen such that it will be never changed ever after. What I meant was you must freeze it temporarily, match it, take feed back, modify as per feedback, freeze it ... and the cycle ... Every time you freeze it and the implementation that corresponds to it qualifies as a "Production Release" or "Spec complete" for that version of the specification.
Why bother freezing a specification you're going to modify anyway, especially given that almost all of the modifications in the Perl 6 specification in the past couple of years (if not longer) have come at the request of implementors?
How is your proposal not a game of semantics dusted with a light sprinkling of unnecessary ceremony? Being able to point to any specific version of a specification won't change the fact that anyone remotely responsible and intelligent will have to evaluate any given release as to its actual qualities and not merely adherence to a specification that everyone knows will change from feedback anyway.
I don't even know who Royce is, much less his paper.
Royce was a founder of software project management. His 1970 paper is, perhaps, the most influential document on managing software projects. Anyone lecturing other people on how to manage software projects and schedules and scopes and specifications should be familiar with it.