David,
Probably because the plan describes the branching strategy just vaguely and assumes everybody
knows the details? The strategy described is commonplace and tested, so I second it.
Here's probably the missing piece of info that some folks are looking for, to get confidence in
starting the branch?
Every update to the trunk should be monitored by the person managing the release branch. Each
update to trunk should be quickly assessed to see if it applies to the branch (some simple
criteria being "whether the application is for a new feature or existing bugs"). If it applies to
branch, then apply it.
And vice versa. Every update or bugfix to the branch should be assessed to see
if it applies to trunk.
That way, all fixes done on today's releases will be carried forward to
tomorrow's releases.
Hope that assures everybody that "anytime, really, is a good time to branch for
release".
By the way, we may often find ourselves having to apply just a sub-part of a patch to trunk. So,
`svn merge -r ${revision-1}:${revison} http://svn.apache.org/repos/asf/incubator/ofbiz/trunk' may
not always work, but may even create new bugs in the release branch instead.
Also, over time, as the release branch and trunk diverges, the release branch maintainers could
complain that it's too difficult to "apply apples to oranges". And that should be the time to
discontinue maintenance for that branch.
Jonathon
David E. Jones wrote:
This is a very relevant topic, but it might be helpful to in terms of
the existing Release Plan:
http://docs.ofbiz.org/display/OFBADMIN/Release+Plan
I don't see people referring to this much or talking in terms of "this
is the plan, but maybe we should do it X way because of Y". Is that
because the Release Plan is just total crap, or maybe it's too long and
not worth reading?
But yeah, these things are addressed in the Release Plan.
-David
On Apr 17, 2007, at 10:05 AM, Jonathon -- Improov wrote:
What about simply forking a release branch now, and then we work on
stabilizing and debugging THAT branch?
As and when new fixes go into the trunk, we can merge those fixes into
the branch. Ideally, the release branch will not take in new features
from the trunk, but only fixes to bring the branch towards stability
for final release. I'd recommend using Release Candidates.
I'd be the first one to offer to test the release branch in the effort
to bring it to release status. If there _is_ a release branch, I'll be
basing my work on that branch rather than the trunk, anyway.
If no one else is familiar with this branching strategy, I may be
willing to take on the admin work for this. Just let me know when my
deadlines and what my deliverables will be.
Jonathon
Si Chen wrote:
The SVN right now is in reasonably good shape in my opinion -- it's
been more stable in the past, but there's also been a lot of times
when it's a lot less stable. I think we need to get the framework to
a stable point and resolve any critical applications bugs, and then
it should be a pretty good release.
Having said that, is it better to create a release branch now, or
wait a little bit? This would depend on everybody's development
plans. I notice David and Andy are doing a lot of things in the
framework and base methods and that there have been some bugs that
are being fixed. Could the next few days, week, or two weeks be
spent primarily addressing these issues without a lot of new features
being committed? If so, then it'd be better to wait until then.
Otherwise, let's just make the release branch before a whole bunch of
new but not necessarily critical features or refactorings arrive.
Shi Yusen wrote:
+1 for creating a release branch.
Also, without responses the branch will basically just include
whatever it includes.
As an training course, I have arranged a man to test current HEAD in
different enviroments.
I think the release branch can be created now.
Regards,
Shi Yusen/Beijing Langhua Ltd.
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 269.5.0/763 - Release Date:
4/16/2007 5:53 PM
