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