Now when an alpha is tagged (i.e. it branches off master.xml), the
manifest repository still gets a tag, a commit on master, and a new
build branch pointing at that commit, but by default an additional
commit is appended to the build branch that branches the projects
coreos-overlay, portage-stable, and scripts in the manifest. When
given the --push option, a build branch is created in each of these
project repositories so everything is prepared for future minor
releases to build upon.
This is implemented in yet another option so that the previous
behavior is still available, but it probably makes sense to just
hard-code the default behavior of --branch and --branch_projects
and drop those options.
To make branches easier to use this splits the branch manifest into two:
build-????.xml is now only pins revisions of projects that do not have a
corresponding branch (yet) while release.xml pins all revisions. Unlike
before the script can now be used to tag branched releases.
The step to switch any particular project to a branch is still manual
but that will be a simple future expansion. First this will be migrated
to Go though, this script has hit the limit of sophistication that
should be attempted with mixing XML and bash. ;-)
The existing version.txt is kinda annoying. The common case of referring
to the current version requires joining three values and the names of
those values only make sense in ChromeOS. Instead just use version as a
string, using VERSION, VERSION_ID, and BUILD_ID just as they appear in
os-release. It is up to the few scripts that need the individual parts
to break the version apart.
The old values remain for the sake of compatibility.
- it shouldn't be possible to set the SDK version to the same as the new
tag's version. The SDK must always be a previous build.
- don't fail if there isn't any old manifests to git rm.
There are ways to improve, it'd be sexy if it was truly safe and we
could throw around annoying terms like idempotent to make this kind of
sequence just work but doesn't yet: tag_release; tag_release --push
A number of places refer to these paths and that number is going to
grow. Since the standard pattern is to use environment variables for
commonly used paths it is time to add ones for these:
REPO_CACHE_DIR
REPO_MANIFESTS_DIR
