Re: [seam-dev] Seam patches and SVN logistics
We certainly don't make any requirements like branching for every JIRA. We actually
want people to be able to get something done!
Everyone *must* run the whole testsuite locally before committing. Any major breaking
change will be rolled back if it breaks the test suite (minor stuff, it's better to
fix).
We only create a branch when we need to deviate two streams of code significantly.
Examples are:
* major breaking feature that takes a while to code, and the developer wants some
feedback. The developer is responsible for the branch.
* maintenance release when trunk has moved on (we are releasing 2.2.Alpha1, but 2.1 needs
a fix)
On 18 Mar 2010, at 14:58, Arbi Sookazian wrote:
Hi guys,
Isn't it cleaner/safer to create a new branch for each JIRA issue and then
re-integrate with trunk when that fix/enhancement is complete and tested rather than
having all the devs work directly off of trunk? I know there are more merges involved but
this way if a JIRA is postponed or canceled it's easier to manage/isolate b/c it has
its own trunk for that JIRA issue.
Also, if somebody checks in a change set for a JIRA issue and breaks the build, the
Hudson build will also break if it builds off trunk. And the other problem is that if
another dev wants to 'svn co' from trunk, it's immediately a broken build.
Then you have to coordinate with the developer who checked in the files that broke the
build, etc.
So as a matter of svn best practices, I'm wondering if it's best to create
branches for each JIRA issue (esp. if they're more complicated enhancements, for
example, that involve modifying/refactoring a lot of files and/or adding a lot of new
files) or having all devs work right off the trunk? And maybe the answer depends on if
it's a minor release (e.g. Seam 2.2) or patch fix release (e.g. Seam 2.2.1) or a large
feature release like Seam 3.0....
Perhaps there is a svn URL for each Seam 3.0 module? Is that the strategy to keep it
fairly isolated?
On Thu, Mar 18, 2010 at 7:31 AM, Lincoln Baxter, III <lincolnbaxter(a)gmail.com>
wrote:
Hey Arbi,
Long story short, we're still working on setting up the infrastructure and providing
that information to everyone so they can be on the same page.
Hopefully we'll have this under wraps soon,
--Lincoln
On Thu, Mar 18, 2010 at 1:36 AM, Arbi Sookazian <asookazian(a)gmail.com> wrote:
HI all,
Are there any documented "rules of engagement" or best practices concerning
committing patches, bug fixes, etc. for JIRA issues with respect to Seam 3.0, for
example?
Specifically, do the Seam core devs and miscellaneous committers work directly off of
trunk for all JIRA issues for a particular release or do they create a separate branch for
each JIRA issue which is then reintegrated back into trunk?
If the latter, then what about using Mylyn in Eclipse for task mgmt and context mgmt?
The activation of tasks and tracking of change sets by Mylyn are useful in Eclipse
workspaces where there are multiple JIRA issues (or tasks) to work on and isolate context
for.
And is a continuous integration server like Hudson or Continuum used as well? Is a build
created by the CI server every time a file or change set is committed to trunk or is it
schedule by CRON job?
thx.
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev