Answers: <p>It's likely that you'll eventually find that it will be impossible to keep the plugins truly version agnostic.</p>
  <p>Somewhere along the line one version of the regular code will make an assumption about the plugins that happens to be correct in one version, but changes in a later version. Even if you fix all of your branches to work with newer versions of the plugins, historical commits in those branches won't work with the newest plugins. This can make it difficult to some kinds of debugging (eg: anything with <code>git bisect</code>).</p>
  <p>Instead of having the plugins only in the latest branch, it might be better to have them in all of the branches, and have a policy that changes to the plugins happen only in the latest version branch, and are then &quot;backported&quot; to the older versions' branches by cherry-picking the plugin update commits.</p>
  <p>However, the best is probably to move the plugins into a separate repo and either use a package manager or git submodules. Then each version branch can be explicit about which version of the plugins it works with.</p>
  
Answers: CC BY-SA 4.0
Answers: 2023-09-20T23:17:10.867Z
Answers: the plugins will use feature checks against the products to see what functionality is enabled. that's the plan anyway. And we intend to test them against all supported versions of the product
Answers: Evan Carroll
Answers: CC BY-SA 4.0
Answers: 2023-09-20T20:52:01.500Z
Answers: 2023-09-20T20:52:01.500Z
Answers: Laurence Gonsalves
Body: <p>Our repo at work has branch versions, branch names are like,</p>
  <ul>
  <li>1.0</li>
  <li>1.2</li>
  <li>1.4</li>
  </ul>
  <p>We also have version-agnostic code we're creating now for a plugin system.</p>
  <p>Currently there is a proposal to put this version agnostic code in the latest branch on the repo. Are there any cons this approach we should be considering? Is it problematic to say &quot;plugins are found in the latest branch and work with all branches of the repo&quot;? Are there any open source precidents for this?</p>
  
Comments: CC BY-SA 4.0
Comments: 2023-09-29T00:00:26.487Z
Comments: If the new code is version-agnostic (and doesn't need to be in-tree with each version), why not create it as a separate module and/or library?
Comments: Jesusaur
Tags: <versioning><monorepo>
Title: Version agnostic code in a branch-versioned monorepo?
UserDisplayName: Evan Carroll
ThreadText: # Version agnostic code in a branch-versioned monorepo?
  
  (Asked by: username_0 on 2023-09-20)
  
  Our repo at work has branch versions, branch names are like,
  
  * 1.0
  * 1.2
  * 1.4
  
  We also have version-agnostic code we're creating now for a plugin system.
  
  Currently there is a proposal to put this version agnostic code in the latest branch on the repo. Are there any cons this approach we should be considering? Is it problematic to say "plugins are found in the latest branch and work with all branches of the repo"? Are there any open source precidents for this?
  
  **Tags:** versioning, monorepo
  
  > **Comments:**
  > **username_1**: If the new code is version-agnostic (and doesn't need to be in-tree with each version), why not create it as a separate module and/or library?  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2023-09-20. Score: 0
  
  It's likely that you'll eventually find that it will be impossible to keep the plugins truly version agnostic.
  
  Somewhere along the line one version of the regular code will make an assumption about the plugins that happens to be correct in one version, but changes in a later version. Even if you fix all of your branches to work with newer versions of the plugins, historical commits in those branches won't work with the newest plugins. This can make it difficult to some kinds of debugging (eg: anything with `git bisect`).
  
  Instead of having the plugins only in the latest branch, it might be better to have them in all of the branches, and have a policy that changes to the plugins happen only in the latest version branch, and are then "backported" to the older versions' branches by cherry-picking the plugin update commits.
  
  However, the best is probably to move the plugins into a separate repo and either use a package manager or git submodules. Then each version branch can be explicit about which version of the plugins it works with.
  
  > **Comments:**
  > **username_0**: the plugins will use feature checks against the products to see what functionality is enabled. that's the plan anyway. And we intend to test them against all supported versions of the product  
  
  ---
  
  