1

Regarding my last question: Can 1.0.1 be launched right after 1.1.0?. I learned that releases can be maintained in parallel using SemVer and it is possible to apply it using Git Flow (Reference: Post of Vincent Driessen, https://nvie.com/posts/a-successful-git-branching-model/), of course, doing some adaptions to better achieve an organized and non-confusing branching model.

Parting from this point, I will describe a situation that can occur, considering Developer A maintains release-1.0 and Developer B maintains release-1.1, and in a given project, these branches are maintained in parallel:

  1. Developer A finds a bug in version 1.0.0.
  2. Developer A launches a patch 1.0.1 to fix that bug.
  3. Developer A informs Developer B that found a bug in 1.0.0 and consequently, Developer B would need to launch a fix, certainly a patch 1.1.1.
  • Note: Developer A and Developer B can be the same person depending on the assignment.

From that situation above, I enumerate some questions that converge in the same aspect:

  1. What would be the best approach in that case, merge the branch hotfix-1.0.1 in hotfix-1.1.1 (to avoid rework) and adapt the code according to the codebase?

  2. Do patches need to reflect the same fixes? E.g. patch 1.0.1 needs to necessarily have the same fixes of patch 1.1.1?

  3. Could Patch 1.1.1 have other fixes besides the fixes of Patch 1.0.1?

  4. Can Continuous Integration automates the process of applying patches that fix the same bug? E.g. A single patch that could be applied to release-1.0 and release-1.1. Could be a tool that automates the process of create commits, fix conflicts of merges without human intervention (I don't know if that is possible), or decreasing that interaction to avoid mistakes.

1
  • We don't know. 1.1 must maintain backwards compatibility with the public interface but could share nothing else in common with 1.0, so the implementation change might not apply. It may or may not even have the bug the patch fixes.
    – jonrsharpe
    Oct 12, 2023 at 22:42

2 Answers 2

5

What would be the best approach in that case, merge the branch hotfix-1.0.1 in hotfix-1.1.1 (to avoid rework) and adapt the code according to the codebase?

Merging can be dangerous here, depending on what this branch contains. For example, if 1.0 has received certain updates that you don't want leaking into 1.1, then a hotfix branch made from the current state of 1.0 should not be merged into 1.1 as it will apply more changes than just the hotfix itself.

The easiest but surefire approach depends on a lot of factors that I can't account for here.

  • Sometimes, you can just merge a branch. It's the easiest, but there are cases where it shouldn't be done.
  • Sometimes, a cherrypick solves the problem that you'd encounter in the above bullet point. I don't like cherrypicking but I've seen devs who don't mind and manage to make it work.
  • Sometimes, the "same fix" requires making actually different changes to two versions (e.g. because of heavy refactoring that took place between those versions). In this case, it's way easier to just develop two individual hotfixes.

There's more than one way to do this and your question is way too broad to provide a specific answer.

Additionally, it depends on how complex you're willing to make your branching strategy. I personally steer clear from git's more difficult and granular strategies, but others jumped in the deep end and confidently rewrite commit histories without breaking a sweat. There's a lot of considerations at play here: risk vs reward, your developer's git skill level, the complexity of your codebase, ...

The last consideration I want to add here is that hotfixes tend to be simple changes made to the codebase. They're usually not substantial or complex. You're probably overthinking this approach. Reusability is nice when you can have it but you have to remember that the effort (and risk) doesn't start outweighing the benefit. Sometimes, redoing a trivial fix is the better way if it completely avoids side effects that you'd otherwise be risking.

Do patches need to reflect the same fixes? E.g. patch 1.0.1 needs to necessarily have the same fixes of patch 1.1.1?

The name "patch" really just means "release of a small changeset". Releases can be scheduled however you see fit. Maybe the patch only contains this fix. Maybe you bundle a week's worth of fixes, which could mean that the 1.1 patch contains this 1.0.1 patch and some other things as well. There's no need to keep these kinds of patches equal across all versions. That's the whole point of semver, changes are scoped to the version that they are listed under.

There's also no way of knowing that the same patch number is available in both versions. If you've already developed several fixes in 1.1-specific code (that does not exist in 1.0), then 1.1 will be several patch numbers ahead of 1.0. This might mean that your patch 1.0.1 might end up being patch 1.1.25 for the other version.

Could Patch 1.1.1 have other fixes besides the fixes of Patch 1.0.1?

See above paragraph. Yes, it can contain whatever you want it to contain. It's completely your choice when you release a patch/update and how much it contains.

I frequently develop bugfixes and then don't bother doing an individual release for them, simply because there's no need for going through the motions. Instead, I just "throw it on the pile" and let the fix go out with whatever the next release will be.

While CI/CD does urge you to integrate and release frequently, frequency is a relative concept. For some, that means after every commit. For others, that can mean weekly. It's very contextual based on the work and effort involved.

E.g. A single patch that could be applied to release-1.0 and release-1.1.

1.0 and 1.1 are different in some way (otherwise there'd be no point to having a newer version 1.1). They are also similar in other ways (otherwise you wouldn't think of them as versions of the same codebase).

Whether or not a single patch can be applied to several releases depends on whether the included changeset focuses on the differences between these versions or their similarities.

Ideally, yes a patch could be reused when it fixes something that is the same in both versions. But you can't blindly guarantee that this will be the case, and when you can't guarantee it, it is very difficult (if not impossible) to automate.

I would suggest that you design your process in a way that maximizes the ability to reuse a patch, but to not actually commit said patch without a human reviewer confirming that this patch can be applied to a given version, on a case-by-case basis.

2
  • Parallel development seems hard to maintain in small projects. But now I understand how parallel development works and it is possible to implement it taking the necessary caution to maintain it. A project maintained by a team of developers would keep it sustainable. A solo developer surely would have more work.
    – lvf23
    Oct 13, 2023 at 15:52
  • 2
    @lvf23: Parallel work implies working on two tasks at the same time (i.e. not just starting the second task after completing the first). This is generally not easy as a solo dev but sometimes it's necessary (e.g. halting feature development to focus on an urgent hotfix). I'm not sure if you're conflating parallel development with actively supporting multiple versions at the same time, these are different things. You could work sequentially (i.e. not parallel) while supporting multiple versions, or vice versa.
    – Flater
    Oct 13, 2023 at 23:52
6
  1. merge the branch hotfix-1.0.1 in hotfix-1.1.1

    In most cases, yes. Assuming the changes from 1.0 to 1.1 haven't modified so much of the code base that this merge isn't possible or sensible any more, in which case it may be easier to do the rework for a semantically equivalent hotfix fully manually. Ultimately, it depends on the specific content of the hotfix and the specific changes which have happened from 1.0 to 1.1.

    Note there could exist already patches 1.1.1, 1.1.2 and 1.1.3, in which case hotfix-1.0.1 should better become hotfix-1.1.4 in the 1.1.x development line.

  2. Do patches need to reflect the same fixes? E.g. patch 1.0.1 needs to necessarily have the same fixes of patch 1.1.1?

    Obviously not, see #1. When the necessity for patch 1.0.1 is detected at a point in time when 1.1.3 is already deployed to production (as well as 1.0.0 is the latest production release of the 1.0 line), this would make no sense.

  3. Could Patch 1.1.1 have other fixes besides the fixes of Patch 1.0.1?

    Yes, of course. Think of a scenario where in 1.1 some code from 1.0 was copy-pasted or used as a template for a new function, and exactly this copied code section had a bug which was fixed in 1.0.1. Now, in the 1.1.x line, one may have to fix two places instead of just one to get a semantically equivalent fix.

    More important, there is simply no rule in Git Flow or SemVer that the changeset in 1.1.0 -> 1.1.1 has to reflect the same changes 1.0.0 -> 1.0.1, or that such a change set cannot include other patches as well.

  4. Can Continuous Integration automate the process of applying patches that fix the same bug?

    Unlikely - at least, it would be dangerous. As I wrote in #1, the code evolution might have been so large that the patch 1.0.0 -> 1.0.1 isn't working in the 1.1 line any more, or may break the code (if you are unlucky, this can be true even when a automatic Git merge is still possible without collisions). Or the example I gave in #3 - a CI system could only fix the original function in a syntactically equivalent way, but not semantically, at least not without a large portion of "AI magic".

    In general, you don't want some automated CI process committing any changes to the code base - not without having those changes reviewed by a pair of human eyes first.

1
  • About the question #1: We should assume that when performing a git merge operation, it will do its best to find the common base between hotfix-1.0.1 and hotfix-1.1.1 (as far as possible) and find the conflicts between the bases together with the fixes proposed in 1.0.1, right? There's no way to isolate the patch all alone independent of 1.0 and 1.1, it needs to be dependent on some base. Depending on the number of merge conflicts can be dangerous indeed perform a merge just to apply a single patch since can mix by mistake particular things of 1.0 in 1.1.
    – lvf23
    Oct 13, 2023 at 15:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.