Timeline for Can 1.0.1 be launched right after 1.1.0?
Current License: CC BY-SA 4.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 13, 2023 at 15:57 | history | edited | lvf23 | CC BY-SA 4.0 |
Add a post-answer edit just to add some interesting links and the final observation of the question.
|
| Oct 12, 2023 at 0:16 | comment | added | lvf23 | @ThorbjørnRavnAndersen, I always personally curious about large projects like Ubuntu and WordPress that have parallel versioning. But in my work, Generally, I used and learned the linear perspective to mantain the projects following the guidelines of the company I was working. Since I used the Git Flow for a long time, I had the difficult to visualize the implementation of that projects in that branching model. But now reading the comments, everything makes sense. Knowing new theorical concepts help me apply this in practice and take better decisions for future and current projects. | |
| Oct 11, 2023 at 23:26 | comment | added | Thorbjørn Ravn Andersen | Of course you can create parallel releases. I was wondering if this comes from a specific need of yours or you are doing a theoretical exercise. | |
| Oct 11, 2023 at 22:10 | comment | added | lvf23 | @ThorbjørnRavnAndersen, WordPress mantain releases in parallel, for example. Now I know that releases can be mantained in parallel. Part of my question was if Git Flow would support that parallel versioning. Git Flow seems to follow a linear progress (master with all tags including releases and hotfixes), My question was about the possibility to develop a software where the releases are in parallel, lets say, a Parallel Git Flow (release tags 1.0, 1.1,... in master, patch releases 1.1.1, 1.1.2,... in their own release branches release-1.0, release-1.1, ...) to avoid conflicts in merge. | |
| Oct 11, 2023 at 21:55 | vote | accept | lvf23 | ||
| Oct 11, 2023 at 21:54 | answer | added | Thomas Owens♦ | timeline score: 3 | |
| Oct 11, 2023 at 21:39 | comment | added | Thorbjørn Ravn Andersen | Why would you do this? Are there customers who need to stay on 1.0? | |
| Oct 11, 2023 at 17:47 | answer | added | gnasher729 | timeline score: 0 | |
| Oct 11, 2023 at 8:14 | comment | added | IMSoP | 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). | |
| Oct 11, 2023 at 5:10 | answer | added | Doc Brown | timeline score: 6 | |
| Oct 11, 2023 at 2:06 | comment | added | Alexander | 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. | |
| Oct 11, 2023 at 1:22 | comment | added | Flater | @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". | |
| Oct 10, 2023 at 23:37 | history | edited | lvf23 |
edited tags
|
|
| Oct 10, 2023 at 22:57 | comment | added | lvf23 | @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? | |
| Oct 10, 2023 at 22:28 | comment | added | IMSoP | 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? | |
| S Oct 10, 2023 at 20:19 | review | First questions | |||
| Oct 11, 2023 at 0:27 | |||||
| S Oct 10, 2023 at 20:19 | history | asked | lvf23 | CC BY-SA 4.0 |