I like your release approach in general.
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. (case for branch arises when a package
has after a release first a major version bump e.g. 3.2-->4.0 and then a bit
later a security fix 3.2.1 for the 3.2 in the release.)
And e.g. Openwrt uses nickname & version number confusingly: main firmware
download is from "chaos_calmer" download directory and source branch, while
feed source branches are "for-15.05".
Just make sure that you can keep the terminology clear during the discussion.
I am raising this up now, because include/version.mk logic can be pretty
confusing and your message leaves some things up.
Jo-Philipp Wich wrote at Sat Nov 19 06:20:07 PST 2016:
> ... just two arguments: a release number and a code name.
> ... the version number (or the nickname) alone.
> ... name it "lede-$version"
> ... 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
> ...
http://downloads.lede-project.org/$version/targets/ar71xx/generic/packages/$buildno
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?
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.
I wrote earlier in
http://lists.infradead.org/pipermail/lede-dev/2016-May/000271.html that there
are at least three different kind of branch builds, as people also compile
from branches (possibly already before the release during rc phase, plus
after the release):
- 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)
- branch release builds: Branch codename designation, official release
number, source revision, opkg download from release repo
- branch builds after a release: Branch codename designation, last release
number known + changes after it, source revision, opkg download from last
release repo
So please consider that your script produces sensible config values at the
source repo for all the 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.
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
