Skip to content
This repository has been archived by the owner on Jun 23, 2022. It is now read-only.

ODPi Infrastrucutre

Cos edited this page Jan 15, 2016 · 7 revisions

####Effective branching workflow and naming schema

  • each cloned ODPi repo should have a set of odpi-specific branches, prefixed with "odpi-", e.g. for Hadoop repo it will be odpi-branch-2.7.1 to correspond to branch-2.7.1 (needless to say, cloned repos will contain the original set of the branches from the project-proper)
  • odpi-* branches will carry on the context of a branch from project-proper + whatever modifications to be applied and weren't up-streamed
  • ODPi stack BOM should be pointing to either the odpi-release or a particular odpi- dev. branches and be creating the binary artifacts from there. A component build can either use direct git hash to produce the binaries, or utilize the GH archive generating facility. The latter is much faster
  • during a release, odpi-release-X.Y.Z branch will created to carry on for all branding modifications as needed
  • bringing in the changes should be done via standard PRs into odpi-* specific branches
  • keeping the odpi-* specific branches up with their upstream counterparts needs to happen at regular intervals for actively developed branches, and on a need-to-do basis for released ones.

As a quick example: odpi/bigtop odpi-master branch refers to odpi/hadoop odpi-branch-2.7.1 branch, that has all version modifications for ODPi version of Hadoop component (right now only version string changes).

A suggestion has been made to include ODPi stack version number into the branch name to distinguish different release train. I would like to postpone on implementing such a complication, until we see that is really necessary. See https://jira.odpi.org/browse/ODPI-7 for more details

Working with branches / update-flow

odpi-specific branches need to stop on top of the corresponding upstream branches, when seems reasonable or required. On the other hand, changes would need to be made to these odpi-specific branches. The following work-flow outlines the process. Recommended way to sync-up odpi-specific branch (ie odpi-master) with its upstream counterpart (master)

  • sync up master of the odpi-specific repo with its upstream origin. It could be done directly without involving GH PR. assuming you have two remotes origin for odpi-specific GH repo; and public for its upstream
git fetch origin
git fetch public
git checkout -b master public/master
git push origin HEAD:master
  • fork and create your own clone of odpi-specific repo (yours). Then in it
git checkout -b hotfix-branch odpi-master
# make and commit you changes
git push yours HEAD:hotfix-branch
# Create PR to the *odpi-master* from the new *hotfix-branch* as usual with GH flow.

####Package naming schema

The native Linux package names need to communicate the following info:

  • name of the component
  • version of the component
  • belonging to an ODPi stack
  • version of the reference implementation release (under discussion)

This translates into a package name, which in case of Hadoop HDFS will look like the following:

hadoop-hdfs-2.7.1+odpi_1.0-1.noarch.rpm

####Maven artifacts versioning

Programming artifacts deployed into and used from ODPi public Maven repository should convey the following:

  • version of the artifact, reflecting the version of core component
  • optional number of added modifications or Patch Level (PL>0)
  • the artifact belonging to ODPi stack

In case of Hadoop HDFS, the jar file will look like

hadoop-hdfs-2.7.1.PL-odpi.jar

See https://jira.odpi.org/browse/ODPI-3 for more details

Clone this wiki locally