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