[LEDE-DEV] Release Preparation Questions

[Jo-Philipp Wich]

Hi,

> Right off, I see the term "buildno" being used twice in a "name": 1) "version
> number X.Y.Z ... Z the build number", and 2) "$version/targets/ar71xx/generic/
> packages/$buildno".  This appears redundant, and redundancy is a bad idea in
> this context.

$version will contain just X.Y, there is no redundancy in the URL, example:

http://downloads.lede-project.org/16.11/targets/ar71xx/generic/packages/0

> "Human readability" is an issue here, where "r5" is easier to recognize than
> "git6b40471".  If "information" is not essential *do not* use it in a "name".

Agreed.

> Looking through these posts, I see the following terms used.  I "think" I know
> what some of them mean, but I am naive and am probably misunderstand what all
> these terms *actually* mean.  Still, this is a very long list of terms to apply
> to a unique "name".  If, in fact, each of these "terms of art" are both a)
> distinct, and b) essential, then the "version number", as used in the
> introductory post - "any related resources like download URLs, Git repositories
> etc. are using predictable names which can be constructed from the version
> number" - must contain the entire set of "independent variables", in order to
> convey the required information.  I count twenty independent variables:
> 
>  1) base repository

This is always the same - http://git.lede-project.org/source.git

>  2) external feed repos

Those are described in feeds.conf.default within the base repo.

>  3) feed source branches

Those are described in feeds.conf.default within the base repo.

>  4) release branch number

This is an input variable, major.minor version, usually year.month for
simplicity, e.g. 16.11

>  5) commit tags

These are git tags which exactly match the source state used for
building binary artifacts.

>  6) builds

Builds are the binary artifacts produced.

>  7) master

Always the master branch of #1 - this is a fixed property for the project.

>  8) release branch

This is the branch used for all builds within a major.minor version,
e.g. 16.11.0, 16.11.1 ... 16.11.N are all built from a release branch
called "lede-16.11".

>  9) release number

Always variable #4 + the number of the build being produced from a branch

> 10) branch release builds

Same as #6

> 11) package feeds

Same as #3

> 12) commit hash

Equivalent to #5

> 13) source branch

Equivalent to #8

> 14) subrelease

Any release within a base version, e.g. 16.11.0, 16.11.1, 16.11.2 -
think of them as patch levels - e.g. when images have to be rebuilt with
a newer version of some component due to security updates.

> 15) new release

Term for the release getting prepared.

> 16) security fix

A security fix is an update to a software component in order to address
some vulnerability or undefined, potentially exploitable behavior.

If an optional additional package (e.g. ffmpeg) gets a security fix, the
package is simply rebuilt and people can install it using opkg update;
opkg upgrade ffmpeg.

If a builtin package or the kernel itself gain security fixes, the
images need to get rebuilt since people cannot update those components
with opkg.

> 17) nickname

Symbolic name given to an entire release branch, e.g. all 16.11.*
releases will carry the same nickname.

This is similar to Debian where the 8.0, 8.1, 8.2, 8.3, 8.4, 8.5 and 8.6
releases are called "Jessie" even if they're different "patch levels" or
"sub versions" of the Debian 8 release.

> 18) code name

Same as #18.

> 19) version number

Same as #9.

> 20) main firmware

No idea what you mean with that.

> You know the drill: Pretend that you are explaining this to a grade-school
> child.

I can try.

> My naive first impression is that, if the LEDE build process actually
> *requires* twenty different conceptual variables to designate a specific
> "version number", then something is probably wrong with the way this process is
> being managed.

No it does not require twenty different variables but it has to deal
with (currently) five independent repositories:

  - git://git.lede-project.org/source.git
  - feeds.conf.default: git://git.lede-project.org/feed/packages.git
  - feeds.conf.default: git://git.lede-project.org/project/luci.git
  - feeds.conf.default: git://git.lede-project.org/feed/routing.git
  - feeds.conf.default: git://git.lede-project.org/feed/telephony.git

This thread is - among others - about defining a proper process for
coordinated branching and tagging in all these involved repositories to
condense the various repository:branch:revision vectors into just one
version number which then uniquely identifies a revision in
git://git.lede-project.org/source.git which carries a specific version
of feeds.conf.default which uniquely references a particular commit in
each of the external package feed repositories.

Example:

$ git clone git://git.lede-project.org/source.git lede-source
$ cd lede-source/
$ git checkout tags/16.11.0
$ cat feeds.conf.default
src-git packages
https://git.lede-project.org/feed/packages.git^28b4b51ba46ce97c60f45519c5af638b5e38d17d
src-git luci
https://git.lede-project.org/project/luci.git^1c27f6b462b7b488e75a5388198e97be00ba0835
src-git routing
https://git.lede-project.org/feed/routing.git^34a2618d2e41030df6cadbb0b8ff0272df34943c
src-git telephony
https://git.lede-project.org/feed/telephony.git^1f0fb2538ba6fc306198fe2a9a4b976d63adb304

> Still, I would encourage, a) writing-down an "essential" and "official" list of
> terms to be used in creating a LEDE software "release", b) explaining those
> terms to some naive person, and c) see if that person understood you.

I will get to it.

> So far, *I* do not understand what you guys are talking about - and I've been
> doing this open source software thing for over twenty years.

Did you ever build the complete LEDE or OpenWrt from scratch?


Regards,
Jo