title: How to semantic-release a patch to a version that is on QA while Dev has a new minor that should not be deployed to prod?
body: <p>Our build/release process works as follows:</p>
  
  <ol>
  <li>AWS CodePipeline triggers AWS CodeBuild when a PR is merged</li>
  <li>CodeBuild jobs run tests and build the node package, uses semantic-release to determine the version number with <code>eslint</code> commit format, and build the docker container</li>
  <li>AWS CodeDeploy deploys this container/service to the <code>dev</code> environment</li>
  <li>A Manual Gate sits after, which when opened deploys the container/service to the <code>QA</code> environment</li>
  <li>A similar Gate sits before <code>prod</code></li>
  </ol>
  
  <p>Now imagine that version <code>v1.5.2</code> was deployed to <code>Dev</code> and then deployed to <code>QA</code> via the manual gate.</p>
  
  <p>Then a different PR for a different feature was created and a <code>v1.6.0</code> was release and pushed to <code>dev</code>.</p>
  
  <p>But QA found that <code>v1.5.2</code> had some bug that was not discovered in unit tests or while testing on <code>dev</code>.</p>
  
  <p>So now we need to release <code>v1.5.3</code> to <code>dev</code>, but will not be able to, since <code>v.1.6.0</code> has already been released.</p>
  
  <p>Arguably <code>v.1.6.0</code> already contains all of <code>v1.5.2</code>, however the patch should be applied to <code>v1.5.2</code> since we may not want to rollout <code>v1.6.0</code> to <code>prod</code> for example, but we do want to get <code>v1.5.2</code> out to prod after fixing whatever bug was found on QA.</p>
  
  <p>I have scoured the "semantic-release" docs and issues, but only found what says we cannot do it:</p>
  
  <blockquote>
    <p>Finally semantic-release makes releases for every new commits on
    master in the order they get pushed. If you merge commit A to master,
    semantic-release run and publish a release, then when you merge commit
    B, same thing. The second release will have a higher version number
    than the first one. If for some reasons you want commit B to be
    released first then it has to be merged first. This behavior is
    extremely important, because it guarantees that your git history match
    your release history. You don't have to have a change present in 1.1.0
    but not in 1.2.0.</p>
  </blockquote>
  
  <p>Taken from reply to <a href="https://github.com/semantic-release/semantic-release/issues/1213" rel="nofollow noreferrer">issue 1213</a></p>
  
  <p>Short of modifying the commit analyzer, is there any way to achieve what we've described above?</p>