all my changes are in seperate components.
currently my attention is 10.4 branch, which I keep updating in a test
instance.
1)load and configure my componets
2)ant run-install
check logs and operation related to my components.
what usually happens is I get log errors do to changes that are not
compatible from 9.04.
3)connect to postgresql
4)load data from production server into this test instance.
set entityengine so will not update db.
5)run code so get logs reports of data changes
6)see if any effect my components
7)got through the compoents to change.
8)ant clean-all
9)clean the postresql and turn back on add tables.
10)run migration of production data to changed db for 10.4
first time workeffort was a few manweeks.
each subsequence update of the 10.4 does not exceed a manweek.
=========================
BJ Freeman
Strategic Power Office with Supplier Automation
<http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist
Chat Y! messenger: bjfr33man
Adam Heath sent the following on 12/9/2010 3:22 PM:
On 12/09/2010 05:11 PM, BJ Freeman wrote:
> [snip, just want to talk about the next paragraph]
If everyone stop contributing the way they do(little or no intensive
testing, and upgrade paths), maybe I could get release stable. So I
don't see the "gifts" as that.
What do you mean, getting a release stable? Are you deploying new
applications on trunk, and then after the deployment, continuing to
upgrade to the latest trunk each time, in a production environment? If
so, then don't do that.
In all the various open source projects I have been involved with,
*none* have ever done full upgrade testing, full system regression, on
trunk. Only when the set of features stablizes, and a real release is
iniment, does final upgrade testing occur, and release notes get finalized.
A feature added to trunk during a development cycle may end up getting
completely rewritten, or removed, before the next stable release comes
out. If we follow your design practice, then every single change will
have to come with full deprecation of old features, full upgrade
support, and nothing will actually get implemented.
Here at brainfood, our current ofbiz deployments are based on svn
902021. There was nothing special about that particular version. I just
happened to have time to create a new ofbiz.deb package(we use debian
internally). Since then, there have been 447 commits to our local
package, and 42 separate package releases. 99% of those changes are
backports(actually, we use git, so they are called cherry-picks)
directly from trunk. I've been able to do this all on my own, a single
person, in addition to my other duties. It has not been a huge sap on my
personal resources.
