Message-ID: <715404136.84414.1397664821902.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_84413_1407080700.1397664821902" ------=_Part_84413_1407080700.1397664821902 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Sketch out anything in the Wiki and prepare for making it
somethin= g people can look at.
Put it on the proposals page: http://docs= .codehaus.org/display/MAVEN/All+Proposals=20
Put the proposal up for a vote to see if people agree. All these
c= an be vetoed as it's a technical decisions.
You're good to go,so you can start the process of implementing
you= r changes.
Create a feature/change branch and start working on your code.
Pu= tting a link to your work in progress in the Wiki. The goal is to
nev= er destabilize the main line be that the trunk of version branch.
Ok,= so the new features start on trunk but the new feature is a
branch o= f trunk. The point being feature additions don't destabilize
the trun= k. The series of branches associated with issues also
provides a clea= r path of what happened, branches named with something
like MNG-123-A= ndMaybeSomeQuickDescription make it easy to know what
it is and to lo= ok up the issue. For dead simple fixes things can go
into the trunk b= ut anything requiring more then a few hours of work
should go into a = feature branch of trunk. When it's merged back into
trunk, if it's po= ssible it is then merged back into any version
branches (like 2.0.x).=
You now document the new features or changes that you have
impleme= nted and detail and compatibility issues. You must have at
least one = other core committer review your changes to be deemed
You move your proposal to the approved proposals section of the
Wi= ki and it becomes a record of the evolution of Maven.