The terms I normally use are Change Request for things that need to be changed due to modified requirements, and Problem Report for things that need to be changed due to errors.
These are collected, and then scheduled for specific update cycles. If a cycle is internal only, it is called a Milestone, if it is deployed to customers, it is called a Release.
A typical timeline has a few milestones before the release, called Release Candidate that undergoes extensive testing, and any errors found there generate further Problem Reports that are again scheduled for either the next milestone if they are important enough, or a later release if not.
It is also possible to create a Branch that only addresses specific PRs in response to customer complaints, with a separate release that has no further changes, in the hope that fewer errors are introduced here. This is usually only done if the effort for updates is low enough (e.g. because updates can be installed simply by plugging in an USB stick with a file with a certain name on it).