[LEDE-DEV] Release Preparation Questions

[Jo-Philipp Wich]

Hi all,

I am currently on working on automating the required steps to cut a
proper release - in order to make this process as standardized and
repeatable as possible, I intend to script any required steps to avoid
the need for manual setup tasks as much as possible.

Ideally I want to reach a point where one runs a "make_release.sh" with
just two arguments: a release number and a code name.

In order to achieve that goal, we must ensure that any related resources
like download URLs, Git repositories etc. are using predictable names
which can be constructed from the version number (or the nickname) alone.

Below is a list of things I'd propose for automating release cutting,
please let me know if you agree or think otherwise.


REPOSITORY PREPARATION

1) Branch "source.git" and name it "lede-$version"

2) In the used package feeds, branch "lede-$version" and use it

3) Use http://downloads.lede-project.org/$version/ as base
   download URL

4) In the "lede-$version" branch, adjust
   package/base-files/image-config.in to have proper defaults for
   CONFIG_VERSION_NICK, CONFIG_VERSION_NUMBER and CONFIG_VERSION_REPO,
   also default CONFIG_VERSIONOPT and CONFIG_VERSION_FILENAMES to y

VERSIONING

1) Images shall have a version number X.Y.Z where X is the year of
   release, Y the month and Z the build number produced by buildbot

2) The nonshared base repository holding kmods will be copied for each
   consecutive build, so there will be a

http://downloads.lede-project.org/$version/targets/ar71xx/generic/packages/$buildno
   for each build in order to ensure kmod compatibility even for older
   installed images

3) All other, sharable repositories will remain at the base version, eg.
   http://downloads.lede-project.org/$version/packages/mips_24kc/base to
   let older installed images benefit from updated packages

SIGNING

1) We generate a new GnuPG key pair per release and cross-sign that
   with multiple developer keys listed at
   https://www.lede-project.org/signatures.html

2) We generate a new usign/signify key pair per release and use that to
   sign the package lists - NOTE: we currently lack any support for
   cross-signing usign signatures so we need to figure out a solution
   for that

If no one objects to this I'll start implementing the points above in
the form of a series of release scripts which we can then use bootstrap
the release process.

Regards,
Jo