Answers: <p>So what is happening is that the changed code just sat until internal testing was done (never a good thing as this is how code get stale quickly).  Once internal testing was ready, the code was then merged into the trunk causing it to be published into nugget under the trunk's feed.  Some business politics ensued and we finally got to a real single code base mindset from the product owner's perspective (which was the issue that got us into this situation).  Moving forward I don't anticipate this to arise.</p>
  
  <p>Code can be branched out.  However, only code in the trunk will go to our internal nugget feed or our build/deployment processes.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-08-22T15:19:53.903Z
Answers: 2017-08-22T15:19:53.903Z
Answers: xtreampb
Body: <p>Our company has a product line and most development happens on the trunk.  We had 3 releases slotted back to back with the last one being an update to the first one.  the first one is in 3rd party testing with the second in in house testing.  The development of the third is completed but due to the amount of breaking changes was done on a separate branch of the first two.  This code needs to be placed on nugget to prevent any checked in code from referencing the local developers computer.  I don't want to make a nugget package for this branch as it will just die/get pruned when it goes into internal testing.  I also don't want to override the current package as internal testing may require changes to be made, causing confusion in version numbers.</p>
  
  <p>What is the best way to manage/publish branched DLLs using NuGet?  should NuGet even be used?</p>
  
Tags: <nuget>
Title: Managing branched DLLs in nuget
UserDisplayName: xtreampb
ThreadText: # Managing branched DLLs in nuget
  
  (Asked by: username_0 on 2017-07-21)
  
  Our company has a product line and most development happens on the trunk. We had 3 releases slotted back to back with the last one being an update to the first one. the first one is in 3rd party testing with the second in in house testing. The development of the third is completed but due to the amount of breaking changes was done on a separate branch of the first two. This code needs to be placed on nugget to prevent any checked in code from referencing the local developers computer. I don't want to make a nugget package for this branch as it will just die/get pruned when it goes into internal testing. I also don't want to override the current package as internal testing may require changes to be made, causing confusion in version numbers.
  
  What is the best way to manage/publish branched DLLs using NuGet? should NuGet even be used?
  
  **Tags:** nuget
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2017-08-22. Score: 1
  
  So what is happening is that the changed code just sat until internal testing was done (never a good thing as this is how code get stale quickly). Once internal testing was ready, the code was then merged into the trunk causing it to be published into nugget under the trunk's feed. Some business politics ensued and we finally got to a real single code base mindset from the product owner's perspective (which was the issue that got us into this situation). Moving forward I don't anticipate this to arise.
  
  Code can be branched out. However, only code in the trunk will go to our internal nugget feed or our build/deployment processes.
  
  
  ---
  
  