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
Related
Is it possible to make a release from custom branch (not develop)?
I tried to use startCommit command, but Maven JGitFlow plugin has been switched to the develop branch before release is started.
Also, when I changed git configuration manually, it was automatically changed to develop.
I would like to use following steps:
release-start - create release branch
release-finish - create tag, merge to the master and develop, update pom.xml versions.
Issue found
Create a branch from tagged version
Fix issues there
Make another release from that branch
It seems that the parameter startCommit (http://jgitflow.bitbucket.org/release-start-mojo.html#startCommit) is not enough because that provokes an exception with m5.1 (https://ecosystem.atlassian.net/browse/MJF-284). Using flowInitContext seems to work though (http://jgitflow.bitbucket.org/release-start-mojo.html#flowInitContext). You just have to adjust the develop branch (source branch for release branches) to point to your custom branch.
The only thing which cannot be achieved that way, is that during release-finish a merge back to the global develop branch is done. Usually you also don't want to merge back to master (since that may provoke git merge conflicts), which need to be resolved manually.
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.
I am thinking about a deployment pipeline using SVN, Jenkins and Maven. At the moment I'm stuck at the point where I usually would call mvn release:perform on a working copy.
When thinking in deployment pipelines, I want to create a pipeline where every commit could be used to release a software to test/production. Let's say I have 5 builds, and I decide to release build 3 (with revision 3) to production. There will already be 2 new commits to trunk (which is now at revision 5).
Is it possible to use the maven-release-plugin to checkout/build/tag/commit a release at revision 3? When the maven-release-plugin finishes the release it usually commits the modified POMs to trunk.
I'm happy about any kind of information or advice here, so feel free to point me to books (like http://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912), blog posts, Jenkins documentation... Maybe I'm completely on the wrong track.
By default, the release plugin creates the release based on the contents of your working copy, it just ensures that you don't have any uncommitted content before doing so. AFAIK it doesn't force an update of the sources, as that's usually the job of the Continuous Integration system (Jenkins in your case). So whatever is checked out by Jenkins will be released.
What you're trying to do sounds more like a configuration change on the Jenkins side, pointing it to the right revision.
On the other hand, if the POM files are modified as part of the release, but have been changed in SVN in the meantime, you will run into a conflict when Maven wants to check in the modified POM files. That's a situation that might happen, depending on how for back you want to go with the release.
Based on this, it might make more sense to always create a branch before doing a release. So you would create a branch based on revision 3 and then create your release in that branch. This way, you wouldn't run into issues with committing resources that have changed in more recent revisions.
Creating the branch and checking it out could probably be automated through Jenkins and Maven as well.
As far as I tested it, it is not possible.
More explicitely, as nwinler said, when you release, maven try to commit the modified pom. But, if it's an older revision than the current one, SVN will complain that your sources are not up to date. So it won't work. ... as far as I know.
You may read docs about promotion build. I don't find any one clear enough to be pointed out (in th few minutes of the writing of this message).
I'm learning how to use the Maven Release Plugin and I have a question with the process of tagging/branching. I'm working on a project called "test" version 1.0-SNAPSHOT. I'm ready for the release. I can prepare the release and perform the release but Maven only creates a tag and I also want a branch for maintenance (bug fixes). I know that there is a possibility to branch with the Release plugin, but the branch goal doesn't create a tag also. I understand that when you want to branch, you don't want to tag. But, generally when you create a tag from the trunk (because release 1.0 in this case), you would want to branch for future maintenance.
Is there a way to configure the prepare/perform goal(s) to also branch the project before or after creating the tag?
Thanks
AFAIK no. But simply copy the /tag/test-root-1.0 to /branches/test-root-1.0. Then you need to update the versions in the pom. For this you can simply use the "mvn versions:set" goal and set the version to "1.0.1-SNAPSHOT". You are probably up to scripting these two commands in bash script if you need to make it look as one :-)
You might want to consider integrating the maven-scm-plugin into the mix. Either scm:tag or scm:branch before or after your release goals should do the trick.
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.