CODEWITHSUNDEEP
gitnpmpackage-managerssemantic-versioningnpm-publish
Stals
Stals

Reputation: 1603

npm - Merge patch to higher major versions

Currently, we have a single git repository for shared internal packages, with each package being its own folder. Multiple independent projects add dependencies to these packages with shared code.

Because of different release cycles, different projects can depend on different major package versions and may need to publish patches for their current version. For example, Team A is on version 1.0.0, and Team B is on 3.0.0. To fix a bug in the 1.0.0 you would just create a new branch from the commit containing 1.0.0, (say there is not enough time to update to the latest version, that includes some breaking changes), make your changes and publish a new 1.0.1.

Should you also merge your changes to master and also release a 3.0.1? If you wouldn't, then Team B will not get the fix. Even though 3.* is two major versions up, doesn't mean its a totally different codebase, it can be 99% similar, aside from two small breaking changes that caused the major version to be bumped two times.

Also, if at some point Team A will decide to update to the latest version, if you didn't merge the fix to master, the fix will not be there, and that may lead to some rare bug reappearing.

If merging is the correct way to handle this, is there some npm functionality that will allow me to not forget to merge my patch to master? Or even to all major versions higher than the one I'm fixing (or even all minor versions), because what if Team A will decide that it's easier to update first to 2.* ?

If there isn't any functionality like this, am I missing something? Isn't releasing patches to older versions too error-prone and can lead to losing some of the bugfixes? If so, should you prevent older versions from being published?

Upvotes: 1

Views: 451

Answers (1)

LeGEC
LeGEC

Reputation: 52186

More details are coming, but the bottom line is :

At some point, it will be a developper's decision to evaluate if the fix has been included, or if more fixing is needed.
This decision will obviously require reviewing and testing, and possibly writing some extra code.

Let's list some ways to port the code from branch A to branch B :

  1. actually merge branches using git merge :
git checkout v2.0
git merge v1.0

git checkout v3.0
git merge v2.0
  1. use rebase or cherry-pick :
# if the fix consists in one or two commits, it is easy to cherry-pick these commits :
git checkout v2.0
git cherry-pick <fix-commit1> <fix-commit2>

# 'rebase' is a convenient way to apply a sequence of cherry-picks :
git checkout v1.0
git checkout -b v2-port
git rebase --onto v2.0 <from>..v2-port
git checkout v2.0 && git merge --ff-only v2-port
  1. have a developper manually write the fix on branch v2.0 and commit

Here are some elements to know :

  1. merging :
# if your history looks like that :
 *--x--a--b--c  <- v1.0
     \
      *--*--*--*--y <- v2.0

# merging will turn it into something like that :

 *--x--a--b--c------
     \              \
      *--*--*--*--y--m <- v2.0

This has two effects :

  • all the features and fixes from branch v1.0 will be brought along (this may be a good thing or not a good thing, you have to decide)
  • git now knows that a,b,c have been integrated to branch v2.0, and future merges will not try to take them into consideration (this is generally a good thing)
  1. rebasing, cherry-picking :
  • this allows you to choose more easily to pick a portion of v1.0, and not bring along the other portions
  • the result will be new commits, which are unrelated to the pre-existing ones, so remembering that "fix 123" has already been applied should be tracked in some other way (mention an issue in the commit message, for example)
  1. rewriting manually the fix

It's probably not the way to follow ; however, if git merge or git rebase trigger too many conflicts, fixing the conflicts may eventually sound a lot like writing the final fix manually.
Similarly, reviewing the code and testing may highloght some differences, which need to be fixed to match the specifics of your other versions.

I'm merely mentioning this way to highlight the fact that, ultimately, you are the ones to know what is "the right fix" to port to v2.0.

Upvotes: 1

Related Questions