Dave Miner wrote:
> 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
>>
>> So MICROREV and BUILD_ID are only different in that BUILD_ID has a
>> prefix, which people are accustomed to seeing on builds.
>>
>
> It appears to me to be unnecessary complication. Where are you
> expecting they'd see this BUILD_ID displayed?
>
As I've been saying, it is currently only for the point in the installer
when the existing Solaris instances are displayed to the user. I can
drop build ID here if no one wants to see it.
> Dave
>
>
> _______________________________________________
> caiman-discuss mailing list
> caiman-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>
