[LEDE-DEV] Release Preparation Questions

[James Feeney]

Hmm - A few comments from a naive outsider -

> 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

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.

> 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"

"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".

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
 2) external feed repos
 3) feed source branches
 4) release branch number
 5) commit tags
 6) builds
 7) master
 8) release branch
 9) release number
10) branch release builds
11) package feeds
12) commit hash
13) source branch
14) subrelease
15) new release
16) security fix
17) nickname
18) code name
19) version number
20) main firmware

You know the drill: Pretend that you are explaining this to a grade-school
child.  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.

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.

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.

James