If there are “known issues,” why release?

Have I seen many APIs that list details about information problems? If there are known issues, why should they be published before publication?

What is the reason? Dates? Or a fix that could break something else?

Note. I am not sure if this question belongs. Therefore, do not hesitate to close if this is not a question.

+6
release management
source share
19 answers

The software is not perfect and waits until each problem is fixed, to release something, will lead to a world without software.

+32
source share

Because the software is useful and useful, even with problems, and because users would prefer it sooner than waiting for the release. Because its developers want the feedback that released it early to provide.

+12
source share

There are always known issues. If you do not release until more known problems appear, you will never release. Sometimes it’s better to get an accessible version in most cases with warnings about some non-critical issues.

+9
source share

Often, new software is still better than previously available versions, even with known issues. Especially when it comes to libraries, customers would often prefer the code delivered before it has problems, rather than waiting for problems that they don't care about fixing.

+6
source share

Known issues often affect a small number of users, and everyone else can really use the improvements in the new version. Moreover, the same problems may exist with the existing version, in which case there are no new (known) errors to users. So this is truly a victory.

Some problems can take a long time.

+5
source share

Profit

Real world software of any complexity will never be perfect. There is a certain point where he is "good enough", however, and that when he goes on a ship.

The real debate comes when you decide what level of quality corresponds to the “good enough” bar.

+5
source share

Sometimes you cannot fix these problems.

Imagine you have a JS script and some browser error that you cannot avoid. You wouldn’t release your library until this browser is fixed, right? Or you can simply add a “known issues” note about one browser issue and release it.

+4
source share

Otherwise, you never released.

+3
source share

Known issues are in order. These are unknown problems that cause problems.

+3
source share

Because the software is stable . If there are several known issues that do not directly affect the day-to-day use of the software and that can be fixed in patches, then why not let it go?

In addition, there are deadlines and costs that need to be considered, but obviously the latter does not apply to Open Source.

+2
source share

The main reason is MARKET TIME

0
source share

Sometimes the advantage of releasing something that works is more important than the problems that only some users will encounter.

Errors may be minor or critical: S

0
source share

If this is a weak impact (affecting multiple users or possibly internal), this may be one of the reasons. Others may be large wigs who want to enter the market and the market as soon as possible, so sometimes things should be left incomplete based on a number of factors.

0
source share

In particular, with open source projects, this allows most users to get the product without problems, and also increases error awareness so that users can contribute to the code.

0
source share

If a known problem affects only a small percentage of potential users, then it is probably worth releasing.

0
source share

An API is a contract between an API developer and a programmer using an API. Even if the implementation has known issues, it’s useful to publish API documentation so that programmers can start developing code that can use the API. It is clear that the implementation provider (ultimately) will fulfill its contract, bringing the implementation to full API compliance. If the API was released only when the implementation was perfect, application developers were forced to spend a huge amount of development time in which they could be productive, even if they were based only on API documents, and they could not actually verify the code yet .

0
source share

"Commitment".

This is more important.

After the delivery date is completed (Commited), the product must be released if it is at an acceptable level. The Difference Between Perfection and Recognition - Known Issues

0
source share

Most firms have release criteria that may look like

There may be some minor bugs in the software release, the number of which is limited - such problems may be minor user interface problems.

There may be some major bugs in the software release, the number of which is limited. Attempts to make exemption free of such errors, but if they are still hiding (for various reasons), then they should not break the product, and there is some work around to get around them.

There should be no critical errors in the software release. Software is not sent if a critical error is detected. Such errors break the product without any workarounds.

Again, the above classifications may not be available to the objective and depend on the company and their processes.

amuses

0
source share

Check out the benefits of an early / release release policy often, for example. invaluable feedback from your users.

0
source share

All Articles