I'm currently in the process of implementing CD with a Feature Branch Workflow. What's unclear to me is when to increase the version number.
Shall it be increased when a new feature is created?
So let's say we have version 1.1 and I'm going to implement a new feature FB-123.
When creating the FB shall I increment the version?
*---*--- increment build number, now on 1.2.456
/ increment version to 1.2
---* 1.1
And use the Jenkins Build number for subsequent commits?
I would consider to use the following versioning schema:
Every major/minor release is tagged with a git tag
branches schema - <major>.<minor>.<number of commits from latest minor>-<feature branch-name>-<sha1>
master schema - <major>.<minor> (it considers that every accepted pull request is a minor release)
You can calculate the number of commits from latest minor by
git rev-list HEAD ^<latest minor tag> --ancestry-path <latest minor tag> --count
This schema will allow you to derive from the version name:
the base version
the branch name
the git commit that the version was built from
to compare properly 2 versions of the same branch
Related
Spring framework has many dependencies and many versions.
For example: project A -> version 5.0.0
project A -> version 4.x.x
I saw their repository and faced with many branches, like these:
3.x, 4.x, 5.x
My question is:
If there is a bug that exists in versions 3.x, 4.x, 5.x, how they will fix it?
They will fix in all branches? how "Version Control works in this case? They maintain many branchs to be able to fix bugs or do some improvements?
It depends on the SCM system and the strategy.
If you e.g. use git, you can use git cherry-pick.
This command copies a commit to another branch.
For example you can fix it in 3.x (lets say abcd is the commit hash), you checkout the 4.x branch and run
git cherry-pick abcd
You can also use merging (in git).
You could e.g. have a branch where both 3.x and 4.x branch off (or an empty branch).
Then you apply this fix in that branch.
Finally, you can merge this branch into 3.x and 4.x
When I was using
mvn jgitflow:release-finish
I noticed that the release branch got merged into master branch.
Question: Is this the correct way?
Sorry my questions might be naive as I am new to this. I was thinking that the code from release branch will merge to develop and master and not like release --> master --> develop.
Question: What if I don't want this to happen and instead I should be in a position to rebase develop from master?
When I was using mvn jgitflow:release-finish I noticed that the release branch got merged into master branch. Is this the correct way?
This is the correct way according to the main philosophy behind, gitflow:
Release branches
May branch off from:develop
Must merge back into: develop and master
And according to the plugin documentation, the release-finish indeed merges back to the master and dev branch:
finishing a release - runs a maven build (deploy or install), merges the release branch, updates pom(s) with development versions
This makes sense, because (again back to gitflow):
When the state of the release branch is ready to become a real release, some actions need to be carried out. First, the release branch is merged into master (since every commit on master is a new release by definition, remember). Next, that commit on master must be tagged for easy future reference to this historical version. Finally, the changes made on the release branch need to be merged back into develop, so that future releases also contain these bug fixes.
I was thinking that the code from release branch will merge to develop and master and not like release --> master --> develop.
The order follows this flow (first master, then develop) because it's a release and as a release it must firstly go to master (which should always represent the released code base), then to develop (whish is the next potential release code base).
What if I don't want this to happen and instead I should be in a position to rebase develop from master.
You can use the noReleaseMerge option:
Whether to turn off merging changes from the release branch to master and develop
Default value is to false, hence by default merges are performed. However, the option covers the two merges, you cannot disable only one of them, it's either both (again, following gitflow philosophy) or none. This option may suit your needs but you would then perform additional actions via git commands.
We'd like to increment the minor version of our application each time we create a new branch for release. So if, for example, the current version is 4.17 the next branch we create would automatically increment the version number to 4.18.
Our scheme is that the code follows the following path:
Dev -> Test -> Staging
so that the testing happens on code we think has the functionality required and only that code that passes testing is available for release.
Then when the time comes for a new release we take a new branch of Staging, so we have the following structure:
Staging
|----> Release 4.1
|----> Release 4.2
...
|----> Release 4.17
There is no cross pollination between the release branches.
So what we need is something that will increment the minor version number when a new branch is taken. We can reset the version number of the application in Dev/Test/Staging to anything that needed for this to work.
Is this possible with TFS/VS 2013 out of the box?
That is a bad smell!
You have to do that on one branch, and no in all... And not change the assembly number in a manual way...
The TFS Versioning could help you to do this.
In the community build tools you will find an activity called TFS Version. This tool can, in its default configuration, strip the version number from the build name. If you name your build for the branch to be mybuild_7.8.0$(.r) the tool can be configured to pick up that version and store it in a variable. You can then use that variable to update the AsemblyInfo.* file versions.
This is the correct way to do what you are asking. Do not check the changes in, and indeed set the checked in numbers to be 0.0.0.0. This way you will be able to identify when a cheeky developer has done a local push and when it came from a build server 😃
https://tfsbuildextensions.codeplex.com/wikipage?title=How%20to%20integrate%20the%20TfsVersion%20build%20activity&referringTitle=Documentation
I'm trying to put in place a way to permit to developers to be able to sometimes apply a patch on an already delivered version of an application.
before any delivery to a pre-production env we've to release our app.
code versioning system is CVS
here's the use case :
date 1 : we release the application (with maven) which will be deployed on the server (webapp)
date 2 : on (head) there had been commits
date 3 : a bug appears on the pre-production env and we've to deliver a patch, the problem is that we already committed some unfinished features they must not appear on the pre-production env.
I proposed to checkout the code from the already released version (the one of date 1), make the fix and then release from that version.
My question : Is it possible? what will happen to head?
You can do it as follow :
Suppose that the your tag is 1.0
1 - create a new branch (named for example 1.0-hotfix) from the tag of release (1.0 )
2 - checkout the new branch in another local directory
3 - Make changes to your source, commit and release !
4 - finally merge the branch into HEAD
For maintenance and patches you need to be able to work on parallel versions. Usually this is done with the concept of branches, cvs support this feature.
Maintenance branch are very common to apply patch to older versions.
Nothing will happen to head.
While cvs or svn support branches, the implementation in DVCS such as git is much better. Switching to a DVCS would save you a lot of time in the long run.
How do you handle versioning in a continuous integration environment where there is a development branch and a release branch? I'm using git so there is no incrementing repository version to use. Seems like there will be overlapping versions such as 1.1.0 on the dev branch and 1.1.0 on the release branch. Do you just append the text "dev" or "release"?
Also, when you create a release branch do you immediately increment the development branch to the next "proposed" release number? You may not know the next release number yet but if you don't increment it then you have 1.1.0 dev containing new work not included in 1.1.0 release.
So my main question is what is the relationship in the versioning sequences between these two branches?
Keep in mind, I'm not asking anything about how to decide what version numbers to use. I tried asking this before and kept getting comments like "increment major for breaking changes" etc.
I don't version the dev branch. The devline is the trunk and I periodically branch from dev to a new release folder. So the release branch is full of folders which are basically snapshots of the devline.
IE, under root I have /dev, /releases/0.1, /releases/0.2, /releases/1.0, etc.
I'm not sure if this really answers your question.
I would recommend set a final activity for your CI environment to make tags. I believe the git command looks like this: git tag -a name
We use Major.Minor.Release.BuildNumber
though some places use Major.Minor.Release.CheckinNumber
So, if you want to use that then I would version your dev branch, otherwise just version the release branch.
If you have only one development branch, it is more effective to make it be the trunk and branch off a release branch every time you just want to stabilize for release. If you have multiple feature projects, you can have a branch for each of them with CI setup on those. Once they are done, you merge them one by one to the trunk and once all are merged, you get to the first scenario, where you branch a release branch off of the trunk again.
In any case, you don't keep the development branch going between releases. You want to end it and start a new one for development for the next version. This way some of the features can be branched off during several releases if they take longer. But also you don't have too much mess on your development branches.
You can branch the development branches for the next version as soon as you branched the release branch or even before if you chose to, but it is generally good idea once you stabilize for release, merge the changes from release branch into trunk and from there into the development branches if you do that. If you wait with branching off after release, you avoid few merges there, but you slow down development.