Access to add and change pages is restricted. See: https://cwiki.apache.org/confluence/display/OFBIZ/Wiki+access

  • Created by Unknown User (swapnilmmane), last updated by Unknown User (adityasharma) on Oct 18, 2019 3 minute read

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 31 Next »

Code Repository

We already have read-only Git mirrors for the OFBiz Subversion repository. There are two mirrors, before release16.11 and another is after the release16.11.
Since release branch 16.11, we disentangled the plugin components (under the specialpurpose folder) into a separate repository called OFBIZ-PLUGINS


release16.11 and previous releases

https://github.com/apache/ofbiz/

Trunk and releases after 16.11

Framework - https://github.com/apache/ofbiz-framework/

Plugins - https://github.com/apache/ofbiz-plugins


  • Communicate with ASF Infra team to enable write access in the above repositories.
  • After successful migration to Git, mark the SVN repository as read-only

Workflow

As nicely explained by Unknown User (taher) in the mail thread, here details on workflow.

The contribution workflow for small features/bug fixes and large features.

Small Features / Bug Fixes

Small features follow the exact same workflow that currently exists in SVN.

You do your work, diff it, and attach the patch to a JIRA and request a commit from one of the committers.

Large Features

For large features usually multiple people need to collaborate on a separate branch. Here is where git shines and the distributed model kicks in:
1. A JIRA is created for a large feature.
2. The team (not necessarily having a committer) creates a remote repository which itself may have many branches with the master branch having all the work agreed upon and merged (actually, rebased)
3. The collaboration for this branch happens in the JIRA including discussions, comments, and even links to the commits, etc ...
4. A request is made to the project, to make a pull request from the repository after reaching a certain milestone with consensus from the community of course.
5. Here, for extra safety, the branch model may have a trunk and a develop branches. Everything is pulled to the develop branch and trickles down to the master branch after thorough and proper testing.

The above workflow can also adhere to the now famous Vincent Driessen git branching model found here -> http://nvie.com/posts/a-successful-git-branching-model/

Buildbot configuration with Git (Build Scripts)

  • We should make sure the buildbots are enabled on the commits for the above mentioned repository.

Revert workflow

The git revert command can use be revert a commit, more details can be found here.

git revert <commit-revision>

Backport the fixes

In SVN we have script to merge and commit the fixes from trunk to release branches.

All the releases are branches in the repository of Git, we can write similar script mergefromtrunk.sh(bat) and mergefromplugins.sh(bat)  

Release management

We will have a branch for the release management, currently we have three branches in https://github.com/apache/ofbiz-framework/

trunk, release17.12 and release18.12

Cut a release

In OFBiz, we cut a release and thoroughly test it and then finally make it available to the public.

To create a new release, a branch will be cut from the trunk.

Ideally, the branch will be cut from the trunk branch. So make sure you are on the trunk branch.
Here is the example, we have cut the release19.06.

git checkout -b release19.06
git push origin release19.06

Publish the release

Once the branch is ready to publish, we will cut a tag to the release branch. As per our example above we can cut a tag release19.06.01

Here is the example, we have cut a tag for release19.06 branch.
Make sure you are on release19.06 branch

git tag release19.06.01
git push origin release19.06.01

Equivalent of svn:auto-props properties

As mentioned by Unknown User (jleroux), we should have an equivalent of svn:auto-props properties on the server.
Something we will need to not forget when we will switch to Git: https://help.github.com/articles/dealing-with-line-endings/#per-repository-settings

Update the website, wiki documents, and references

After the successful migration to Git, we should update this information to various resources like website, wiki documents, and references.

Migrate svn pre/post commit hooks

As mentioned by Unknown User (deepak), we have hooks on commits, like the word limit in a line for Java file.

  • Check and migrate the svn pre/post commit hook for Git.

Update the RAT tool if needed to use git repository

  • Check if we are using any RAT related thing, and impact of using Git repository on this.





  • No labels