What you describe is (I guess) essentially this: https://www.atlassian.com/git/workflows#!workflow-gitflow
and I know it (we have projects following this pattern) and it works pretty well; this is *not* the workflow that OFBiz community is currently implementing. Theres is no right or wrong workflow... it depends on the project and requirements. The fact that your company is following a different workflow that works for you is great but it doesn't mean that the OFBiz community has to act accordingly. I am wide open to discuss the migration to different workflows and tools (like Git) but for now let's stick to what we have and not on what you have decided for your company. Jacopo On Aug 21, 2014, at 8:13 AM, Hans Bakker <mailingl...@antwebsystems.com> wrote: > Jacopo, > > Sorry to react on your comment at the end of your post below. > > May i ask you to study continuous deployment? Up to now the trunk was always > very stable. Once in a while some problems, but they never lasted more than a > couple of days. > > At AntWebsystems we are supporting continuous deployment (expect a linkedin > post on this) and we upgrade our production OFBiz version every month by hand > picking a trunk version which we think works. Then this version will run on > our demo server for one month and when no problems will be put in production. > This is working fine for the last 3 years. > > So what we are doing is upgrading the ofbiz core system every month, which a > step in the direction of continuous deployment. However, the goal is that > before any commit is going into trunk it should be tested (selenium and > junit) and approved by at least another committer (peer review) > > I would like to know how others think about continuous testing and continuous > deployment. If you make the master (sorry trunk) branch deliberately unstable > and not create development branches, you kill the continous deployment > principle. > > You want innovation? > 1. Convert to GIT > 2. install Gerrit for peer review > 3. Install Jenkins for running all tests daily, also run tests for the > development branches > 4. Do not allow any change in the master branch ofbiz system without a > successful junit or selenium test and peer approval. > > then you will have a production ready 'master' branch most of the time and > the demo server can act as a staging server. > > Regards, Hans > > > > > On 21/08/14 12:41, Jacopo Cappellato wrote: >> On Aug 20, 2014, at 10:26 PM, Jacques Le Roux <jacques.le.r...@les7arts.com> >> wrote: >> >>> This is one reason which would refrain me to jump right now. With of course >>> all the burden and especially the inherent risks of permutation. >>> >>> I think that Pierre's idea of a branch is a reasonable compromise >>> >>> Jacques >> Of course, if we will ever try the switch to Gradle, this would be done in >> the trunk only, not backported to releases; so the instability period will >> only affect the trunk. >> This is exactly the purpose of trunk vs release branches. >> The fact that there are persons that use the trunk in production, and that >> don't want it too change much because this may cause them to work to keep >> their custom tools/code up-to-date, is a burden that slows down the >> evolution of OFBiz. >> >> Jacopo >
