We are changing some of the naming conventions of Zynthian. Future major versions will each have a name. This is not just a marketing gimick. It helps us with managing the development, testing and release processes as described in more detail below.
The next release will be named “Oram” to honour Daphne Oram, an amazing early pioneer of electronic music. Daphne was a British audio engineer who pioneered the use (and misuse) of tape to create soundscapes.
What you need to know
If you use the stable Zynthian release then you do not need to do anything. Any hot-fix patches for 2401 stable will be available via the current manual update mechanism. When the next major version is released, you will have the opportunity to manually select it for update or (as we recommend) install a fresh image onto a separate microSD card.
If you are one of our intrepid testers, i.e. you are currently on the testing branch then you have a choice. You can stay there and test any hot-fixes to the current stable version or you can switch the the oram branch. Please be aware that oram is substantially different to stable / testing so this is a big change. Only do this if you feel confident in doing so. As always, we recommend backing up your data and using a separate card for such significant changes.
If you are already using chain_manager branch then please switch to oram which is directly derived from chain_manager. There will be no further development of chain_manager and the branch will be deleted soon. (Please note that other stale branches will also be deleted so if you are on a branch not mentioned in this post then it may soon stop working.)
Detail
Here is a more detailed description of the new deply process.
Each version will have a code name. The next release will be called oram. (Please note we use lowercase for the git branches. This is git best practice.) The git branch called oram will be used as the development and alpha / beta / release candidate testing until the release of the next major version at which point the oram branch will become the staging branch for any hot-fix patches to that version. This means that you can join the testing at any point and remain on the same branch all the way through to stable release and if you choose to remain on that branch, get the hot-fixes to test before they are applied to the stable version.
When we release the next major version, we will create a tag called, oram-YYMM and apply it to that release version (git commit). (YY is the year and MM is the month of release.) Another tag oram-YYMM.0 will also be applied which indicates this is the first, unpatched version of this stable release. Users may opt to use the oram-YYMM version which will get hot-fix updates or they may choose to use oram-YYMM.0 version which will never change. A new, named branch will be created to act as the development and testing branch for the next major version.
After release there may be significant bugs that need to be resolved. These will be fixed and tested in the staging branch (called oram for the next release) and then a new tag called oram-YYMM.1 will be created and the existing oram-YYMM tag will move to the tested version. This means that a user update will receive these tested hot-fix patches. (oram-YYMM always points to the latest stable release of the oram version and each point release is also tagged, allowing roll-back as required.)
I hope this makes sense. It isn’t really that complicated. You choose:
- Stay on 2401 stable if you wish to maintain the current behaviour and receive hot-fixes (via manual current update mechanism)
- Stay on testing if you want to test hot-fixes to the current 2401 stable version
- Move to oram if you want to enjoy and endure the bleeding edge development
, but I was curious about how much dangerous was the zone… 