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.

 

GroG

8 years 7 months ago

MaVo says :

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