For a software project I am working on, we have a 'dev => QA => production' methodology. That is, we create a release candidate (deployed to Artifactory), give it to QA (deploy to QA systems and a QA backend/application server) who takes a week or so to look at it, and if they it's ok, we make a production release.
Now, I come from an embedded/native app background, not as much Java/systems/CI. And I am accustomed to revision control organized with all releases tagged (in this case, the production release tags are always just copies of an RC tag).
branches/1.2 branches/1.3 tags/1.2.0-rc tags/1.2.0 tags/1.3.0-rc tags/1.3.1-rc tags/1.3.1
However, several team members state that this doesn't work well with Maven (and maybe Jenkins too). Instead, they suggest:
branches/1.2.0-rc branches/1.3.0-rc branches/1.3.1-rc tags/1.2.0 tags/1.3.1
I am arguing that a release candidate should not be a branch, as we need to deliver a known entity to QA (as opposed to a continuous integration/deployment situation where we might cut the production release directly from our development line without waiting for QA). The fact that several developers are checking code into the RC branch, and there is little control around it, has caused issues.
Could somebody please explain if there's something about Maven or Jenkins that would make the second way "better"? Is there anything that makes the first way more difficult to implement?