gitflow VS semver

For us it was git-flow (https://github.com/nvie/gitflow). A straightforward yet effective way to impress momentum in the use of basic strategies: master branch is for production, feature/... for developing new stuff, devel(op) branch for preparing next release (merging feature and hotfixes), release/... for release candidates, hotfix/... for zero-day or fixes on production... Absolutely nothing new, absolutely easy to do.

As a beginner - each of stash, branch, staged and remote is just a swimlane, kinda like illustration here: https://nvie.com/posts/a-successful-git-branching-model/ but can't remember where did I read it initially

Another thing that other suggested me in the comments is to use trunk-based development, which from what I understand is to only create branches directly from master, for anything you do: bugfix, hotfix, feature. Keep them short-lived, then merge back to master. It also sounds like a good idea for me (I've been getting so many options in this short time and overwhelming). Do you think trunk based development is also a good idea? It soudns similar to what GitHub suggests (GitHub Flow: https://docs.github.com/en/get-started/quickstart/github-flow), and even the guy I first got the idea of the drawing above, suggested to use something like GitFlow: https://nvie.com/posts/a-successful-git-branching-model/

Please, also consider that the GitFlow's owner himself nowadays discourages teams from using GitFlow, as he commented in his web page https://nvie.com/posts/a-successful-git-branching-model/

if you can perform all steps described in this doc (which is similar to what most companies do), you are good: https://nvie.com/posts/a-successful-git-branching-model/

There is git flow approach in place, which usually means multiple feature *branches exist at the same time in a remote repository. There is at least one *pull request per story. Each pull request needs to go through an integration* process* meaning the newest commit in a pull request triggers a fresh CI build. That’s being done in order to ensure the newest change won’t introduce any flaws. Yep, automation and unit test suites test each software incrementation. Software Engineers in Test (SET) writes automation tests as “a part of“ the feature in some cases.

This is more easier version of that: https://nvie.com/posts/a-successful-git-branching-model/

Under Linux I use gitflow and gitversion. The former helps me with branch and tags management, the latter keep tracks of the semantic version in a semi-automatic fashion (given a branch/commit/tag it generate a semver automatically based on the repo log). Gitflow should be supported by GUI tools too, but I'm more a CLI guy.

Manage change in automation: Changes to your infrastructure should be made using automation and IaC Tool, such as CDK or terraform. The changes that need to be managed include changes to the automation, which then can be tracked and reviewed, for example, in a VCS such as git and services such as GitHub with a branching model, such as git-flow.

Kotlin obviously doesn't follow Semantic versioning, they've taken the liberty to deprecate 'stable' API's to fix inconsistencies and keep the language modern, and that's one of the main selling points of Kotlin.

I am trying to follow the semantic versioning practice (as recommended), so my pyproject.toml file has the initial version set to version = "0.1.0". (I didn't set it up before but that's fine - I'd like my next version to be 0.1.1 after some additional changes). I expect to manually change it, create a tag, and push that to my main branch for the action to run.

If you are using/consuming Dependabot this GitHub Action is for you. It's a real time saver! It allows to automatically Approve and Merge Dependabot's PRs based on Semantic Versioning update type.

Using semantic versioning, those 0.x version upgrades specifically are for added features. Major version upgrades (e.g. 1.0 to 2.0) are to indicate breaking changes.

2023 promises a gentler transition to Nuxt 4, with a consistent release cycle (following semver), patch releases roughly weekly and minor releases roughly monthly. Overall, we should see fewer, if any, breaking changes.

B) Version your "working chunks!" (I like https://semver.org/)

Semantic Versioning (also known as SemVer) is a widely-used method of versioning software releases. It uses a version number in the format of X.Y.Z (Major.Minor.Patch), where:

From semver.org:

Generating the next release version (semantically) based on the changes, then writing it to the pubspec.yaml file.

In the software world, we use something called Semantic Versioning (https://semver.org/) when it comes to versioning the things we create. It uses three different numbers, all of which have a specific meaning, for example, "v1.2.3". The semver website explains what they mean in the software world, in your case it could mean something like (given X.Y.Z):