I have seen many APIs which list the details about know issues? If there are known issues why release it to public before fixing them?
What is the reason? Dead lines? Or fixing that can break something else?
Note: I am not sure whether this question belongs here. So feel free to close if this is not a valid question.
Known issues often affect a small number of users, and everyone else could really use the improvements in the new release. Moreover, the same issues may exist with the existing version, in which case, no new (known) bugs are being given to the users. So, it really is a win.
Some issues may also take a long time to fix.
Software is not perfect and waiting until every issue is fixed to release something will result in a software-less world.
Because the software is usable and useful, even with the issues, and because users would prefer to have it sooner than wait for the release. Because its developers want the feedback that releasing it early will provide.
There are always known issues. If you don't release until there are no more known issues, you'll never release. Sometimes it's better to get a mostly-working version out the door with warnings about some non-critical problems.
Often times the newer software is still better than previously available versions, even with the known issues. Especially when dealing with libraries, clients often would prefer to have code delivered sooner that has issues than wait for issues they don't care about to get fixed.
Sometimes the benefit of releasing something that works is more important than issues only some users will be struck by.
Bugs can be minor or critical :S
Sometimes you just can't fix those issues.
Imagine that you have a JS script and some bug in a browser that you cannot avoid. You wouldn't then release your library until that browser is fixed, would you? Or you could just add a "known issues" note about one browser problems and release it.
Profit.
Real world software of any complexity is never going to be perfect. There's a certain point where it's "good enough," however, and that's when it's time to ship.
The real debates happen when deciding what level of quality meets the "good enough" bar.
If it's low impact (affecting few users or maybe it's internal) then that probably one reason. Others may be big-wigs wanting stuff out and in the market ASAP so sometimes things must be left incomplete based on a number of factors.
Especially with open-source projects, this allows the majority of users to get the product without problems and also raises awareness of the bugs so users may contribute to the code.
Known issues are fine. It's the unknown issues that cause the trouble.
If a known issue only affects a small percentage of potential users, then it's probably worth releasing.
An API is a contract between the implementor of the API and the programmer using the API. Even if the implementation has known issues, it is good to release the API documentation, so that programmers are able to start developing code that can take advantage of the API. It is understood that the provider of the implementation will (eventually) fulfill their end of the contract, bringing the implementation into full conformance with the API. If the API were only released when the implementation was perfect, then the application developers would be forced to waste a huge amount of development time in which they could be productive, even if it was based on the API docs alone, and they couldn't actually test the code yet.
Because the software is stable. If there are a few known issues that don't directly affect day-to-day usage of the software and that can be fixed in patches, then why not release it?
Plus there's deadlines and costs to consider, but obviously the latter doesn't really apply to Open Source.
"Commitment".
That is more important.
Once the delivery date is finalized (Commited), product must be released if it is in "Acceptable" level. The difference between "Perfection" and "Acceptance" is "Known Issues"
Hi
Most of the firms have a release criteria which might look like-
Software release might have some minor bugs whose count is set to a limit - Such issues might be minor UI issues.
Software release may have some major bugs whose count is set to a limit - Attempts are made to make the release free from such bugs but if they still escape through (owing to different reasons) then they should not break the product and there is some work around available to get around them.
Software release should not have any critical bugs - The software would not shipped if any critical bug is found. Such bugs break the product with no workarounds entertained whatsoever.
Again the above mentioned classifications might be off the target and depends on the company and their processes involved.
cheers
See the benefits of the release early/release often policy, e.g. the invaluable feedback by your users.