[LEDE-DEV] Release Preparation Questions

[Jo-Philipp Wich]

Hi Hannu,

sorry that some things where confusing, the mail was written in a hurry.

> I would prefer to have clear branches like "lede-16.11" for all the
> repos. Tags will not be sufficient when updates are made to the packages
> after the release and people compile new builds.

I too think that branches are more worthwhile since there is almost
never a good reason to rebuild an old version but we can automatically
create tags (even signed ones) in the form "lede-$version.$buildno" for
each source revision that got compiled by the release build farm so we'd
have tags in the form "lede-16.11.0", "lede-16.11.1" etc.

> Based on the above quotes from your message, I am still not quite sure
> what would be $version.  ("16.11", "Reboot Rabbit" or something else?

$version  = the base version number, e.g. 16.11 - this is what I'd like
            to be the main identifier

$nickname = the symbolic name for a release branch, e.g.
            "Rolling Rabbit" - due to its arbitrary nature I do not want
            it to be part of directories or branch names

$buildno  = the number of the build  produced by the build cluster
            dedicated to building the 16.11 base version, see e.g.
            the "buildnumber" property at [1]

> The only input for your script are "release number" and "code name", 
> but following sentences contain also "version number", "nickname",
> "$version". And then for images also "version number" like x.y.z and
> "buildno" z of that x.y.z.

To clarify: "release number" = $version, "code name" = "nick name".
Build number is a dynamic property specific to the build cluster.

> [...] there are at least three different kind of branch builds, [...]
> 
> - branch builds before release: Branch codename designation, release
> branch number is known but no release yet, source commit/revision
> needed, (no branch opkg repo yet, so either no downloads or from
> snapshot repo if still compatible)

That should be versioned like $version+git$shorthash, e.g.
"16.11+git6b40471". Assuming a branch naming of "lede-xx.yy" it would be
something like:

  echo "`echo $branchname | cut -d- -f2`+git`git log --format=%h -1`"

> - branch release builds: Branch codename designation, official release
> number, source revision, opkg download from release repo

When one builds exactly a tag, it would be simply used as version, e.g.
16.11.1 - the buildbots can override it locally since they likely
produce the build before they tag the repo (to ensure successful building).

Assuming tags in the form "lede-xx.yy.buildno" it would be:

  echo $tagname | cut -d- -f2

> - branch builds after a release: Branch codename designation, last
> release number known + changes after it, source revision, opkg download
> from last release repo

Assuming that for each released build we produce a tag then we would use
the tag as designation plus the current hash, e.g. "16.11.1+git6b40471"
or we can alternatively use the logic used for master and use the last
tag as version number and count the number of commits since it, e.g.
16.11.1+r5"

> So please consider that your script produces sensible config values at
> the source repo for all the cases.

I think the approaches mentioned above should cover these cases.

> Ps. I still hate how config options and include/version.mk mix
> CONFIG_VERSION_NUMBER vs. REVISION/commit, CONFIG_VERSION_NICK option
> vs. hardcoded RELEASE definition, and again CONFIG_VERSION_NUMBER vs.
> "HEAD" for VERSION_CODE.  When looking at the release script, you might
> also consider if the config logic there needs some straightening.

Yes, we definitely need to untangle it, that is why I am seeking input.

~ Jo