jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sébastien Launay <sebastien.lau...@anyware-tech.com>
Subject Re: Branch and backports management
Date Mon, 31 Aug 2009 09:31:22 GMT

Le 30/08/2009 11:07, Jukka Zitting a écrit :
> Yes, that's preferable. You can commit simple things like typo fixes
> or javadoc updates without an issue reference, but in general all
> non-trivial changes should have an entry in the issue tracker and the
> commit message should refer that issue.
That's what i thought.
> We're using the merge tracking feature introduced in Subversion 1.5.
> The basic workflow is to commit the fix to trunk first (unless the
> issue is specific to a branch) and then use the "svn merge" command to
> merge that change to a branch. Alternatively you can simply commit the
> fix in trunk and mark the related Jira issue as fixed for the next
> patch release. The release manager is responsible for checking that
> all (and only) the issues marked for a patch release have been merged
> to the respective maintenance branch.
Ok, i'm familiar with svnmerge wrapper program.
> Yes, though normally we only apply bug fixes to release branches.
IIUC if the merge can not be done automatically, we can update the
release branch manually and then mark the trunk commit as
"already" merged using:
*|svn merge|*|* -*|*|-record-only -r 10000
# where 10000 is the trunk commit revision
in order to avoid merging it again later.
> Note that currently we have two active branches 1.x and 1.6. The 1.x
> branch is there in case we still need to do a 1.7 release based on JCR
> 1.0 and some new features or improvements that can't be made in a
> 1.6.x patch release. It's preferable if any backports from trunk are
> first merged to the 1.x branch and from there to the 1.6 branch. That
> way we can keep the merge tracking records clean.
I did not know there was a 1.x branch to keep in sync.
I understand this branch can be useful when a 1.7 might see the
light of day.
But this branch may also be created from 1.6 when a new release
branch is really needed in order to avoid multiple backports
from branches to branches.
We often have this kind of debate in our enterprise, i just
want to have your position on that.
> The Checkstyle profile in jackrabbit-core/checkstyle.xml is probably
> our most strict style definition, but we haven't been too religious
> about it. We generally follow the standard Java coding conventions
> from Sun (with spaces instead of tabs for indentation) but don't worry
> too much about finer details. See also JCR-97 for the catch-all coding
> style and the good discussion in the comments.

Sébastien Launay

View raw message