Releases versions, build pipeline, branches, tags
Development in this project uses a version of "Git flow" process.
Code gets created in "feature branches" (name convention: feature/xyz). Feature branches are not intended for public access. After particular feature or group is finished and passes basic testing, it gets merged into develop branch.
After some stabilization period/bug fixing etc. code from "develop" gets merged into "master" branch. Code in the master branch represents the latest "stable version".
Note: as of today (2018.09) there is no released "stable version" of v2.1 yet, but it is already very close. Stable enough for daily use.
So basically two branches "master" and "develop" are for "public access". After changes get merged in develop branch, Travis CI build is automatically triggered. Tip of the develop branch is marked by tag continuous-develop. Resulting binary build in form of AppImage is published in Releases. In case you "follow the repository" you should get a notification. Mostly it happens rather quickly - like in 15 minutes after code merge, the resulting build should be published.
Binary equivalents of the current develop branch are published as: releases/tag/continuous-develop. That means if your issue gets resolved, you can use this build to test the changes. Note that you can use the AppImage version even if you installed the Ubuntu version from the NixNote PPA. AppImage version and the PPA version of the same source version are ~equivalent.
It is no problem to have "stable version from PPA installed" and download and try the latest AppImage version of development build. Both with use the same data and config without problem. Just don't run both at the same time (there is a protection against it: if you try to run two NixNote instances - the later one will try to activate the first and quit).
After you finished testing, you can either continue using the AppImage version or simply delete it. AppImage version of the build consist only of one file and if you run the file it doesn't install anything on your system.
Additionally there is a "development branch PPA" available. The usage is same as for "stable PPA", just replace the name "nixnote2-stable" with "nixnote2-develop". Just please take care, that you don't enable both stable and development PPA. At most times, the "development release" should be OK for daily use.
After stabilization period/bug fixing code from develop branch gets merged into master branch. Merge triggers Travis CI build and stable version of the AppImage should be published as releases/tag/continuous. Again it should happen in like 15 minutes after merge of the changes.
Then normally after few hours Launchpad pickups the changes and the Ubuntu NixNote PPA is updated. Latest version from PPA and latest continuous build should be ~equivalent. After the PPA is updated, installed package on your Ubuntu system should automatically update (according how did you update settings). You can force update if you want it immediately after it was published.
After some milestone is reached, tip of the "master" branch gets additional marker called "tag". Version numbering follows "Semantic Versioning". To follow the naming convention from the upstream in the created "git tags" there is additional prefix "v".
Tag example: "v2.1.0"
According to semantic versioning - stable release numbers never contains hyphen.
Example of finding latest release:
$ git tag --list | grep '^v' | grep -v '-' | tail -n1
v2.0.2
Unstable releases have additional "suffix" after hyphen. Tag example: "v2.1.0-beta4"
According to semantic versioning - unstable release numbers always contains hyphen.
Additionally the type of the release can be identified by containing the word "alpha" or "beta".
Example of finding latest non-alpha release:
$ git tag --list | grep '^v' | grep -v alpha | tail -n1
v2.1.0-beta3
Because builds are published also between the "releases" - see continuous/continuous-develop builds, in order to make reporting bug easier, after each change there is additional alphabetical suffix. The version number then looks like "2.1.0-beta4c".
"2.1.0-beta4c" is then a version somewhere between tags "v2.1.0-beta3" and "v2.1.0-beta4".
See also: HowTo - Check used application version
Wiki Index ** FAQ ** Getting started ** Features