0

I know that it is common for software to have parallel development in major versions, such as v1 (1.x.x), which can be completely different from v2.

Regarding Semver (Semantic Version), can I upgrade to a patch version (e.g., 1.0.1) right after launching a minor version (e.g., 1.1.0)? Let me describe a situation that I would like to achieve in chronological order:

  1. Launched a major release 1.0.0.
  2. Launched a minor release 1.1.0.
  3. Launched a patch release 1.0.1 (Is that possible or can I not launch retrocompatible patches? Note that the patch is for 1.0 and not for 1.1. In that case, is it the right way to launch 1.1.1 and not 1.0.1?).

The master/main branch are generally linear with another branches merging into it. Would it not be inconsistent merge into master the branch of 1.1.0 before branch of 1.0.1 since their branches started with different parent commits?

P.S. I would like to use the Gitflow Workflow (master, develop, release-x.y, hotfix-x.y.z, etc) but adapt something for the better of this scenario I described above.

Post-Answer Edit: Observing the behavior of parallel branching model, where all the tags are not necessarily chronologically sequential (E.g. 1.0.0, 1.1.0, 1.0.1, 1.2.0, 1.1.1, 1.0.2, ...). I can conclude that:

  • Minor releases inside a major release are always sequential (E.g. 1.1, 1.2, 1.3, ...). There's no way to launch 1.2 before 1.1.

  • That behavior repeats in patches inside a minor release (E.g. patches of release 1.1: 1.1.1, 1.1.2, 1.1.3, ...). Patch 1.1.2 can't be launched before 1.1.1.

I would like to share some interesting links that in a certain way are related to this question for further reading:

Improve this question
9
  • 1
    In terms of SemVer: yes, you absolutely can and should release like that, if you have an important bug fix to get out (it's particularly common with security fixes, backported to as many branches as possible). In terms of git itself, there's also no problem. But it seems your actual question is how to combine this with a particular branching workflow?
    – IMSoP
    Commented Oct 10, 2023 at 22:28
  • @IMSoP, can you please post for me a example of a repository, a documentation that applies that? The Git Flow generally merges everything in master/main, I am looking for parallel branches (release-1.0, concurrently with release-1.1 and their fixes (hotfix-1.0.x and hotfix-1.1.x), in that case of parallel branches, the hotfixes should be merged in their release branches only instead of master to avoid the confusion I mentioned in the question?
    – lvf23
    Commented Oct 10, 2023 at 22:57
  • 5
    @lvf23: Your question needlessly ties semver versioning to git versioning, which are two unrelated topics. Yes, you can have a release branching strategy that acknowledges semver versions, but that's just one of many way to skin this particular cat. Just to prove the other side of the spectrum exists, I could have a single branch, with never any other branch created, that has a fully semver-compliant web API with versioned endpoint. This isn't a matter of giving you a doc that describes what you should be doing, this is a matter of "describe what it is that you want to do".
    – Flater
    Commented Oct 11, 2023 at 1:22
  • 1
    You might find Ruby's releases to be an interesting point of reference. They continue to release patches to previous minor/major versions until they hit EOL.
    – Alexander
    Commented Oct 11, 2023 at 2:06
  • 1
    I could trivially find a project where release numbers follow SemVer, but happened to come out in that order. But there's a pretty high chance it wouldn't answer your actual question, if they don't happen to be using the same branching and merging strategy as you. So I think your "P.S." at the end of the question should probably actually be its headline: "How should I handle branches and merging in this situation when working with Gitflow". As others have said, that situation is not about SemVer, it's about needing to backport a fix to an old release (SemVer just tells you what to name it).
    – IMSoP
    Commented Oct 11, 2023 at 8:14

3 Answers 3

Reset to default
3

The rules of Semantic Versioning don't prohibit this. However, whether it makes sense depends on your deployment model. For example, for a SaaS web application or mobile app deployed in an app store, it doesn't usually make sense to release a 1.0.1. However, if you're maintaining a library or framework, you may have different users on different versions and may want to maintain multiple releases through a certain life.

The traditional gitflow solution would be to use the tag in the master branch to create a new hotfix branch and then merged back into the master branch and the develop branch. There are other solutions that involve maintaining release branches for the life of a version, which don't conform to the definition of gitflow. You may also want to consider the need to update multiple versions, such as applying the patch to both 1.0 and 1.1.

Improve this answer
2
  • My problem with Git Flow is only that, using that parallel branching model, hotfixes would be merged in master, causing a serie of merging conflicts, an example of conflict is merge first release 1.1.0, then 1.0.1 (if release-1.1 was created from a commit more old than the commit that originated hotfix-1.0.1), The master tag would be confused too (tags 1.1, 1.0.1, 1.2, 1.0.2, 1.1.1, ...). I think that is more organized tag the hotfixes only in their release branches to keep the tags sequential relative to the release branch.
    – lvf23
    Commented Oct 11, 2023 at 22:21
  • 1
    @lvf23 You can avoid the merge conflicts by rebasing the commits in the appropriate place in the history. Although "rewriting history" brings up other valid concerns. Honestly, a slightly modified gitflow that drops the main branch and only uses develop, release, and feature (where hotfix branches are feature branches off a release branch instead of develop) branches is probably a step in the right direction.
    – Thomas Owens ♦
    Commented Oct 11, 2023 at 23:02
6

SemVer does not contain any rules in which chronological order one has to develop, publish or deploy different branches which are not part of the same sequence. When the end result is

  • a major release 1.0.0
  • a patch release 1.0.1 and
  • a minor release 1.1.0

it does not matter whether "1.1.0" was developed before, after or in parallel to "1.0.1". It also does not matter if 1.1.0 was developed before 1.0.1 and published afterwards.

Hence, from the version number alone, one cannot determine if 1.1.0 was created starting from 1.0.0 or from 1.0.1 and contains the bug fixes which were introduced by the patch. In fact, when 1.1.0 is the successor of 1.0.0, but the patch in 1.0.1 gets integrated into 1.1.0 somehow, this may be almost undistinguishable from a chronology where 1.1.0 was created as a direct successor of 1.0.1. This can only be determined by reading the (hopefully well-maintained) change log of 1.1.0, which should mention it's predecessors.

Improve this answer
2
  • I can agree with you in a linear development model. In a parallel release model, the order of merge matters to keep the code consistent and with less merge conflicts.
    – lvf23
    Commented Oct 11, 2023 at 22:48
  • 1
    @lvf23: I was under the impression it was very clear I am not talking about a necessarily linear development, my answer says actually exact the opposite. And if one gets merge conflicts depends first and foremost if two parallel changes happen in the same area of the codebase or not.
    – Doc Brown
    Commented Oct 12, 2023 at 5:55
0

Not if it is available to the general public. For example, if you write software for an iPhone, and you just released 1.1.0, Apple won't accept any version 0.x.y, or 1.0.x for your application.

If you have a version 1.1.0beta then a previous version number is much more acceptable, for everyone who doesn't want to use your beta version.

Improve this answer
1
  • Good to know that traditional app development usually follows the linear progress. But there are software that can mantain releases in parallel to keep a long term support like libraries, tools like CMS, Programming Languages, Development Tools, etc.
    – lvf23
    Commented Oct 11, 2023 at 22:33

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.