This does make sense (applying bug fixes patches in release 1st, to have
a better documentation in the release branch). On the other hand, then
the trunk will be rather undocumented (regarding "why" bug fixes).
So it seems better to put the documentation (bug fix comment) in both
branches (not only a reference to rev in trunk, or vice versa).
Anybody aware of best practices in this area ?
What do you think folks ?
Jacques
----- Message d'origine -----
De : "Jonathon -- Improov" <[EMAIL PROTECTED]>
À : <[email protected]>
Envoyé : vendredi 27 avril 2007 10:10
Objet : Re: Request to All Committers
Of course, if there is a conflict in the merge or the bug was caused
after
> the release branch was done, then this will require more work or
won't be
> necessary.
Determine what bug the bugfix was trying to fix in the trunk.
Determine if the same bug exists in
the release branch. That is the minimum work required when applying
patches across branches.
As I said before, once the trunk deviates too far from the release
branch, and it gets difficult
to compare "apples to oranges", it may be time to discontinue support
for that release branch,
unless someone steps up and says: "there's a whole lot of us still
using that branch, so let us
maintain it".
> BTW, for everyone watching in this sort of overhead is one reason
why we
> haven't been really excited about doing release branches in the
past,
> but still it's great that OFBiz is reaching the level of maturity
where
> this is possible and happening!
In general, the purpose of the release branch is to have a "quieter
stream" for those who need a
situation where "number of bugs fixed is greater than the number
created". Such a situation is
hardly possible (nor correct) in the trunk stream.
Bug reports should come in for the release branch, not the trunk. The
whole point of publishing
(and using) the release branch is to get more bugfixes and less new
bugs. It's best to fix bugs in
the release branch first, then massage (if necessary) the bugfix for
the trunk. Fixing bugs on the
"quieter stream" should be easier than fixing bugs in the trunk where
bug phenomena could be
compounded by frequent radical changes.
If we find no bug reports coming in for the release branch, then there
is absolutely no interest
in the release branch (or no bugs!). In that case, the release branch
will progress very slowly to
maturity/stability, and the whole community will have to live with
that.
So, those who had complained like "please don't break existing
functionality!" should be advised
to use the release branch. And those who need the "latest and greatest
though less tested" can try
the trunk. And everybody is (or should be) happy.
Jonathon
David E. Jones wrote:
To help maintain the release branch, I'd like to ask all committers
to
keep it in mind as we fix bugs.
If you commit a bug fix to the trunk, go ahead and merge it into the
release branch as well.
This should be pretty easy, just do the following:
1. keep a checkout of the release4.0 branch somewhere on your
machine
(the full URL is:
https://svn.apache.org/repos/asf/ofbiz/branches/release4.0)
2. after committing to the trunk make note of your commit revision
number and go into your release4.0 branch local checkout directory
and
run something like (replacing the rev number there with the one from
your commit):
$ ./mergefromtrunk.sh 532994
This doesn't take much time and it will make it easier for all of us
to
keep the release branch updated with the latest bug fixes that go
into
the trunk. Of course, if there is a conflict in the merge or the bug
was
caused after the release branch was done, then this will require
more
work or won't be necessary.
BTW, for everyone watching in this sort of overhead is one reason
why we
haven't been really excited about doing release branches in the
past,
but still it's great that OFBiz is reaching the level of maturity
where
this is possible and happening!
Thanks,
-David
