11 Matching Annotations
  1. Feb 2024
    1. The increment-after-release model makes sense for branching too. Suppose you have a mainline development branch, and you create maintenance branches for releases. The moment you create your release branch, your development branch is no longer linked to that release's version number. The development branch contains code that is part of the next release, so the version should reflect that.
  2. Jul 2023
  3. Jun 2022
    1. Remove the commit from step 2. We will merge ignoring the failure. Remove the commit from the other, check it passes with the other commit now on main. Merge the other. We will trigger builds for the main branch of affected repositories to check if everything is in order. Steps 5-8 should happen continuously (e.g. one after another but within a short timespan) so that we don't leave a broken main around. It is important to triage that build process and revert if necessary.

      It is important to not leave a broken main around.

  4. Jun 2021
  5. Jan 2020
  6. Nov 2019
    1. But in general the guideline is: code should be clean, history should be realistic.
    2. many organizations end up with messy workflows, or overly complex ones.
    3. If you push to a public branch you shouldn't rebase it since that makes it hard to follow what you're improving, what the test results were, and it breaks cherrypicking