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
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
