Create stable Anduril 2 releases using hg branches
Anduril 2 needs a release process that allows users to install a stable release if they don't want the risks of a development snapshot.
This can be made very lightweight using hg branches. Here is a model: http://nvie.com/posts/a-successful-git-branching-model/
The "default" branch would be a stable version, and "anduril2" (or "dev") branch is the daily development branch. A release can be made simply by merging anduril2/dev to default (after checking that tests are OK).
Currently, default is Anduril 1. At some point, Anduril 1 should move to a legacy branch and default should become Anduril 2 stable.
Same process can be followed for bundles.
Comments (5)
-
-
I created a bookmark called "anduril2_stable". bookmarks can be deleted and added easily, and also moved in place.
To update the current checkout to bookmark:
hg up anduril2_stable
To move the current bookmark:
hg bookmark -f -r [changeset] anduril2_stable
bookmarks need to be separately pushed (exported), otherwise your changes wont be public:
hg push -B anduril2_stable
-
should bundles have their separate stable release -marker, or use the date from the revision of anduril2_stable ?
We should have installation guide for both stable and dev versions of anduril on the web page, but is there something else we should do with the stable release?
-
reporter Bundles should have their separate markers. This way, you can release a new stable version of a bundle even if the core was not updated. It does mean that updating "stable" in the core can break a "stable" in a bundle, but you need to make basic tests (re-compiling) on all bundles when releasing a new core version anyway.
"anduril install" should by default install the stable versions of core and bundles, and latest dev version when given "--dev" or similar flag. The idea is that someone wishing to evaluate Anduril 2 would get safe and tested versions.
-
- changed status to resolved
this must still be documented, but practice has been agreed
- Log in to comment
mercurial bookmarks may be a better solution. you can name a commit with a bookmark, and move the marker as we feel stable point is moved further. (or even backwards)