...
- Release management handover:
The role of the release manager is really important because he is the guardian of the integrity of the source code, release etc.
is created (https://openncp.atlassian.net/wiki/x/C4BIAQ)
Kostas Karkaletsis proposed to create a master pom file for the OpenNCP release who will manage the version of all components of the concerned release because of the number of components and complexity of the current OpenNCP.
Example: OpenNCP-1.0.0 is composend by client-connector-1.0.1 and epsos-ws-server-3.5.0 etc.
It will prevent manual download of the artefacts.
Alexandre Santos: If you build an OpenNCP with master you have to build all components?
TODO: Test faisability of the master parent pom.
TODO: Check credentials into JoinUp server, who could release an artefact.
- Current situation:
Source control tool is Git and hosted into a Bitbucket server (https://bitbucket.org/openncp/) and community release process id described in details Release Management and Release Plan and Actions.
The repository should contain at least 2 branches:
MASTER -->always current production version (for instance: version 1.0.0).
DEVELOP --> source code of next version, this branch has to be always healthy while committing (Jenkins tests and build help to validate the commit). Version+SNAPSHOT (for instance: 1.1.0-SNAPSHOT).
The gitflow model further operates with feature, release and hotfix branches.
Example: New feature name SMP (Gitlfow command in order to create a new branch and start to work here --> then changing Git repository).
Gitflow finish SMP --> merge automatic + delete new feature branch.
Hotfix from master branch + correct + Gitflow finish --> merge master.
Release --> freeze source code into DEVELOP branch and changing Pom file.
All of the samples are executed according the following picture who describes the current way to work with branches:Kostas Karkaletsis, Alexandre Santos, Joao Cunha and S
- Current situation:
...