William Schumann wrote: > Dave Miner wrote: >> William Schumann wrote: >>> Dave Miner wrote: >>>> William Schumann wrote: >>>>> Sundar Yamunachari wrote: >>>>>> My usage of Major, Minor and Micro release doesn't conform the >>>>>> Solaris definitions. Even though OpenSolaris is not going to >>>>>> follow Solaris 10 update model, I am giving an example from >>>>>> Solaris 10. If the system has Solaris 10 update 2 build 6 (may >>>>>> be beta), how will you represent this release? >>>>> For this, I propose: >>>>> MICROREV=<microrev> (optional) >>>>> and >>>>> FULL_VERSION=VERSION.REV[.MICROREV] >>>>> where <microrev> is <micro revision number>[a | b | ...] >>>>> >>>>> Your example would be FULL_VERSION=10.2.6b >>>>> >>>> How is that different than the BUILD_ID? >>> An example of the build ID would be 'snv_79a'. Internally at Sun, >>> build ID is what is currently used to refer to versions. At this >>> point, it's just a different convention for representing the same >>> notion as in FULL_VERSION. Perhaps BUILD_ID could be dropped, but >>> some people might still like to see it. >> >> In the example above, you converted Sundar's build number to a >> micro-revision, so I'm not understanding what the difference is. > Making the first Indiana release as an example: > > $ cat /var/sadm/system/admin/INST_RELEASE > OS=Solaris - could be OpenSolaris, I suppose... > VERSION=11 - major version number > REV=1 - major update number - 1 for Indiana, 0 for Nevada > MICROREV=1 - build number (integer) starting from 1 as build IDs do in > Nevada. Currently, a new build usually comes every 2 weeks. > BUILD_ID=sin_1 - for Solaris INdiana, maybe > FULL_VERSION=11.1.1 > > ...where BUILD_ID=<some string representing Solaris major version> > concatenated with <MICROREV> - For Nevada, this string is "snv_" - if > we still want to keep the notion of a build ID, it might be something > like "sin_" for Indiana. > > ...where FULL_VERSION=VERSION, REV, and MICROREV concatenated with > periods separating them. It repeats information but makes it clear > how a complete version number is composed and standardizes the > appearance. We could eliminate VERSION, REV, and MICROREV as long as > set_release_info() (from this proposal) or some similar convenience > function enforces this format - I don't see a significant difference > either way. > > If I understand Sundar correctly and that his beta is what we refer to > as a respin, > MICROREV=6b for the 2nd respin of build 6, which refers to the same > build as: > BUILD_ID=sin_6b I was not thinking of respin of a particular build. I was thinking in terms of S10 updates. If there are 8 builds for an update, usually build 4 is designated as beta and some customers install the beta. They may upgrade to FCS (which is 8) and the information in the INST_RELEASE can be used to correctly identify that it is beta. In the case of respin, we release only the final respin in the case of S10 updates. I don't know how we will end up releasing Solaris_11/Indiana but our scheme should be flexible to allow various release models.
- Sundar > > So MICROREV and BUILD_ID are only different in that BUILD_ID has a > prefix, which people are accustomed to seeing on builds. > William
