Trunk - Branch - Tag

15331
Reporter: pfilipak
Type: NewFeature
Summary: Trunk - Branch - Tag
Priority: Minor
Status: InProgress
Created: 2014-03-07 18:13:31.469
Updated: 2014-05-23 11:17:19.186
        
Description: Hi

We are using the ALA’s source code, but we have some difficult from it.
Because there aren’t "tags" on repository, so we are not sure what source code can be used for production environment.

I'd like to suggest this link below.

http://stackoverflow.com/questions/16142/what-do-branch-tag-and-trunk-mean-in-subversion-repositories

For example, let's say you start a new project. You start working in "trunk", on what will eventually be released as version 1.0.
	•	trunk/ - development version, soon to be 1.0
	•	branches/ - empty
Once 1.0.0 is finished, you branch trunk into a new "1.0" branch, and create a "1.0.0" tag. Now work on what will eventually be 1.1 continues in trunk.
	•	trunk/ - development version, soon to be 1.1
	•	branches/1.0 - 1.0.0 release version
	•	tags/1.0.0 - 1.0.0 release version
You come across some bugs in the code, and fix them in trunk, and then merge the fixes over to the 1.0 branch. You can also do the opposite, and fix the bugs in the 1.0 branch and then merge them back to trunk, but commonly projects stick with merging one-way only to lessen the chance of missing something. Sometimes a bug can only be fixed in 1.0 because it is obsolete in 1.1. It doesn't really matter: you only want to make sure that you don't release 1.1 with the same bugs that have been fixed in 1.0.
	•	trunk/ - development version, soon to be 1.1
	•	branches/1.0 - upcoming 1.0.1 release
	•	tags/1.0.0 - 1.0.0 release version
Once you find enough bugs (or maybe one critical bug), you decide to do a 1.0.1 release. So you make a tag "1.0.1" from the 1.0 branch, and release the code. At this point, trunk will contain what will be 1.1, and the "1.0" branch contains 1.0.1 code. The next time you release an update to 1.0, it would be 1.0.2.
	•	trunk/ - development version, soon to be 1.1
	•	branches/1.0 - upcoming 1.0.2 release
	•	tags/1.0.0 - 1.0.0 release version
	•	tags/1.0.1 - 1.0.1 release version
Eventually you are almost ready to release 1.1, but you want to do a beta first. In this case, you likely do a "1.1" branch, and a "1.1beta1" tag. Now, work on what will be 1.2 (or 2.0 maybe) continues in trunk, but work on 1.1 continues in the "1.1" branch.
	•	trunk/ - development version, soon to be 1.2
	•	branches/1.0 - upcoming 1.0.2 release
	•	branches/1.1 - upcoming 1.1.0 release
	•	tags/1.0.0 - 1.0.0 release version
	•	tags/1.0.1 - 1.0.1 release version
	•	tags/1.1beta1 - 1.1 beta 1 release version
Once you release 1.1 final, you do a "1.1" tag from the "1.1" branch.
You can also continue to maintain 1.0 if you'd like, porting bug fixes between all three branches (1.0, 1.1, and trunk). The important takeaway is that for every main version of the software you are maintaining, you have a branch that contains the latest version of code for that version.
]]>
    

Author: trobertson@gbif.org
Created: 2014-03-13 17:20:06.705
Updated: 2014-03-13 17:20:06.705
        
Quite correct.  Dave and I discussed the possibility of my becoming a release manager at some point as we get further in the evaluation.  This is how GBIF release all code, and artifacts would be pushed to the GBIF Nexus Repository - the maven release plugin does all you propose, except we would only branch released code for minor patch fixes if there was a real need.  We've never needed to at GBIF (yet) as we can generally get a next minor release out quickly.