Development Process

This page serves as the touchstone for the development process that is used by Maven to manage branches and the trunk during the development leading up to releases.

This thread never really got rounded up, so I thought I'd summarise some points we seemed to be in agreeance on. Please vote +1 for all, or +1/+0/-1 for every item.

• use of the flying fish technique (ie bugfix only release goes over to /branches/2.0.x)
  • we should merge at each point release (2.0.1, 2.0.2) back to trunk
  • can do interim merges if there are long time lines on those releases
  • we need to set up multiple CI processes
• no alphas or betas on 2.0.x releases
• current version is always <final release>-SNAPSHOT, eg 2.1-SNAPSHOT
• 2.1 cycle will have betas (maybe alphas), which are labelled at release time (release plugin to accommodate)
• RC's are the actual build. It will report version "2.0", and is differentiated from the actual final release (if different), by the build timestamp. If the RC is not suitable for any reason, we remove the old tag, and redo the release
• we will setup one new JIRA project per plugin (prefix with just M, won't be reusing the m1 projects, and we'll move all existing issues to there even if closed - based on component)

The same should also apply to Continuum.

If we agree on this, then the first step is:
svn cp https://svn.apache.org/repos/asf/maven/components/trunk https://svn.apache.org/repos/asf/maven/components/branches/2.0.x

and everyone svn switches to that if they are doing core bugfixes. John - can you do this?

-----------------

some things I have written (jesse) general notes on subversion, branching and tagging, dumped here at the behest of jason...cut and copy up as needed..

A little bit about subversion. Tags and branches are functionally the same, and are merely symbolic. making a branch or a tag is not earmarking the file in the repository with a little indicator like it is in cvs, it is logically a copy of the file at that particular revision. with that in mind, tagging is no longer a seperate process from merging...they are no different. The act of tagging doesn't exist. Instead you merge a given changeset from one location to another. svn maintains some amount of knowledge of the file that it was copied from, but not what given changeset was merged into it when.

Common development will take place on the trunk. Work that embody any kind of size or impacts a large array of objects should be done on a special development branch pulled by the developer/s. A note on these branches, I really don't think they should be worked out outside of a couple of weeks...the longer that people spend working on and committing on a branch and not merging that work back onto the trunk the more annoying it will get to finally do the merge. Especially in the infancy of people actually working with branching and merging....it is critical to not let development branches like this get out of hand. If something is going to take over two weeks of development I would consider breaking that development up into multiple phases which each phase being something that can be merged back to the trunk. If API's are going to change, get them changed sooner then later.

There are a number of fundamental things that we need to manage ourselves as developers.

1. my work tramples your previous work
2. my work is getting pushed up the release chain before yours
3. your in a heap of trouble if promoting your changes carries sometime along with it that it shouldn't

first off, work is getting done on the trunk, my commits for project X are getting committed as we go along as I development it on my personal development instance. I feel (or am told perhaps) that it is time to get my stuff moved to QA. Like a good developer I have maintained a list of the changesets that embody my project X, say r100, r105, r106, r109, and r140.

I checkout the release branch and begin merging the changesets from the trunk...all the change sets get shoved into my release branch instance at the same time. I now commit these change sets to the release branch and get me a new r#, say r200 for this instance. I have now aggregated the 5 commits I had made on the trunk into 1 changeset on the release branch. I edit a file called MERGE on the release branch and note that changeset number, the project, and hopefully the jira issue that relates to it. The work is then built and snapshotted and tested... perhaps I have a bugfix or 2 or 3...that get merged to the release branch and added to the MERGE file as changesets representing that Project X of work.

This approach has benefits since it really represents the aggregation of work into larger changesets to deployment. The only side effect it really has is that it doesn't solve the 'my work effects yours, but mine is going first'...but nothing so far addresses that, and if the MERGE file is consistently up to date it can be mined by an external process to protect us I believe. an external process be told what changesets are wanted to be moved from qa to staging and interrogate svn to determine if the changeset for project X masks any files from another changeset being monitored in that same file....this lets us monitor subproject dependencies programattically which would rock.

Pros:

• potential merging of changed code only between developer branches and the trunk
• merging is between trunk and release branches, never between release branch to release branch
• jira tasks for things like javadoc additions and maintanence tasks can be grep'd out of these files, piped through cut, sort and diff to automagically give you changesets to merge to a release tag using xargs
• SIMPLE! if developers keep to the process then releases should be quite simple, just a matter of applying a set of changesets

Cons:

• someone might forget to mark a changeset in the MERGE file, beatings can minimize this though
• same con as everything else, you if changeset X touchs things that changeset Y did...Y has to go forward first, or both have to go...but no system addresses that

another potential mechanism...or naming convention, kicked around a couple of weeks ago.

-SNAPSHOT development suffix for version tags.
-STABLE bugfix suffix for released versions
-RELEASE tag suffix for a released versions

so 2.0-RELEASE is a svn tag that is immutable, it is set once for a set of code, 2.0-STABLE becomes the bugfix branch for the 2.0-RELEASE...and people can track that -STABLE release for something they are assured to be solid and stable...2.1-SNAPSHOT would be development code, released periodically as per whatever rules govern development code release, as needed perhaps

Notes from Garrett Rooney (an svn committer)

his book -> http://www.amazon.com/gp/product/1590592905/103-5910651-7107845?SubscriptionId=08D0B2KAJCAJFBXZGJ02&n=283155

<jason_> any svn users who are familiar with the fly fishing technique?
<jason_> just looking for a little advice on working with branches
<chipig> fly fishing and branches?
<rooneg> i can give advice on working with branches, but i have no clue what you mean by "fly fishing technique" in that context
<jason_> http://cvsbook.red-bean.com/cvsbook.html#Going%20Out%20On%20A%20Limb%20(How%20To%20Work%20With%20Branches%20And%20Survive)
<jason_> rooneg, do you typically work on trunk and merge into the branch periodically or right away?
<rooneg> well, it depends what kind of branch you're talking about. is it a release branch? a maintenance branch? a feature branch?
<jason_> in this case a release branch
<jason_> well, we release from this branch
<rooneg> well, for subversion itself we use a technique like this. when we're ready to start preparing for a release we branch off of the trunk.
<jason_> http://svn.apache.org/viewcvs.cgi/maven/components/branches/maven-2.0.x/
<rooneg> any last minute modifications to the branch happen there (updating change lists, version numbers, etc), then we cut a release candidate.
<rooneg> at this point trunk development continues as usual
<rooneg> there is now a soak period, where the RC is tested. if bugs are found they are fixed on the trunk and then proposed for merging back to the branch.
<rooneg> when we've got enough fixes merged in that a new RC is justified we roll a new RC off the release branch
<rooneg> (rolling an RC means tagging it as well, FWIW)
--> jesse (n=jesse@216-161-72-109.omah.qwest.net) has joined #asf
<rooneg> eventualy one of our RCs is declared final, and we roll the final release with only a version number change relative to the last RC
<rooneg> the release branch (i.e. branches/1.2.x or branches/1.3.x) sticks around and we do basically the same thing for the next release.
<rooneg> the important thing is that all changes go into the trunk first, then get merged into the release branch as needed, so no changes ever get dropped by mistake
<jason_> cool, that's what i wanted to hear
<jason_> thx for the advice
<jason_> what's your name btw? just so i remember
<rooneg> no problem
<rooneg> Garrett Rooney