Kirk Haines wrote:
>>This determination (which I'm sure is not my own) is why all the 0.x 
>>versions baffle me...products that have been (or certainly appear to 
>>have been) feature-complete for months (or years) shouldn't be 0.x. 
>>If it's taking forever to reach 1.0, perhaps the feature list needs 
>>to be re-examined. 1.0 isn't the penultimate world-dominating final 
>>release, it's the initial major release. Just because you thought of 
>>a neat feature during initial development doesn't mean that it needs 
>>to be implemented for 1.0.
> 
> 
> Thanks.  That's a good way of putting it.  This is something that I just 
> never really got my head around before.  Maybe in part it is because in the 
> past almost all of the software and the libraries that I wrote were in-house 
> products that stayed in house, so versions were also internal and I didn't 
> really have to think about it.  Now that I'm trying to be a lot more open 
> with the software tools that I use to get my work done, though, I've found 
> this topic to be the most difficult simple thing I've had to think about in 
> a while.  :)
> 
> I guess the next release of Iowa will be 1.0.  Thanks for helping me sort 
> this out in my head!

Likewise. This makes sense to me. I guess I perceived that some people
were addressing the opposite issue: Should a non-feature-complete
package be made public at all?

To sum up my own thoughts on the matter:

1. A usable, relatively feature-complete, post-beta piece of software
can be version 1.0. If there is MAJOR missing function, or MAJOR bugs,
maybe it shouldn't be.

2. It's OK to release things that are not feature-complete, especially
if you are soliciting aid in working on the project. This is consonant
with the "release often" policy for open source projects (or did it
originate in the XP community?).


Hal