Process To Release

Hi !
I would like to document the process to release MRL.
The goal of which is :

  • clear seperation between development & released code, binaries & repos - such that its stable for end users & "easy" for developers
  • a list of things which must be done in order to provide a release

We currently have "master" & "develop" branches of MRL - this includes the repo.  Some problems potentially still exist on the repo.

We have a Travis-Ci system at our disposal - which builds and tests on each checkin (all branches).  When a tag is pushed it publishes binaries into Github - this is controled by the .travis.yaml file

We need to consider the service pages currently point to pyrobotlab/service (among other places :P) - but really it "should" point to the latest release of example code

Branch for relese is probably not a great strategy - master should probably be always the "latest" release - this greatly simplifies much of the other dependencies..  I'm not really interested in supporting multiple releases anyway - but we do want to support 1 last release - and it should be rock solid.

 


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
GroG's picture

MaVo shouts

MaVo says :

94.103.175.86(it's me MaVo, went checking just before I wanted to go to bed)
94.103.175.86try to don't touch master with deletes or renames (if possible in any way)
94.103.175.86use Github's update-branch feature for updating develop or re-creating develop
94.103.175.86suggestion: merge develop in master - check the difference, overwrite all files in master (maybe check for important changes on master before)
94.103.175.86NEVER rename / delete master if there is not a really big reason !!!