version problems about SDK

version problems about SDK

[Ke, Liping]

Hi, Jessica & Josh

When we are trying to run installer script on lianhao's x86_64 machine, we found if the images are build in two days, according to current version naming convention, some of the packages will be installed to /opt/poky/0.9+snapshot-20101210, some will be to /opt/poky/0.9+snapshot-20101210. 
It will cause problem since we need to know the exact version number before installing and searching some files (environment script file, etc). And the same releases of packages belong to different version (just the build date is not in the same day) seems very strange and hard to handle for us?

Thanks& Regards,
criping

Re: version problems about SDK

[Tian, Kevin]

>From: Ke, Liping
>Sent: Monday, December 13, 2010 2:53 PM
>
>Hi, Jessica & Josh
>
>When we are trying to run installer script on lianhao's x86_64 machine, we found if the
>images are build in two days, according to current version naming convention, some of the
>packages will be installed to /opt/poky/0.9+snapshot-20101210, some will be to
>/opt/poky/0.9+snapshot-20101210.
>It will cause problem since we need to know the exact version number before installing and
>searching some files (environment script file, etc). And the same releases of packages
>belong to different version (just the build date is not in the same day) seems very strange
>and hard to handle for us?
>

I think Josh has laid down the base for multiple version SDK support. The only problem is:

SDKPATH = "/opt/${DISTRO}/${DISTRO_VERSION}"

which obviously is not what we want. We need a similar variable like SDK_VERSION, which
is incremented only when SDK team thinks there's a need for a new version release or
else it keeps same in the life cycle of current version.

Liping, could you try to come up a new variable for your purpose?

Thanks
Kevin

Re: version problems about SDK

[Zhang, Jessica]

[-- Attachment #1: Type: text/plain, Size: 1342 bytes --]

Tian, Kevin wrote:
>> From: Ke, Liping
>> Sent: Monday, December 13, 2010 2:53 PM
>> 
>> Hi, Jessica & Josh
>> 
>> When we are trying to run installer script on lianhao's x86_64
>> machine, we found if the images are build in two days, according to
>> current version naming convention, some of the packages will be
>> installed to /opt/poky/0.9+snapshot-20101210, some will be to
>> /opt/poky/0.9+snapshot-20101210. 
>> It will cause problem since we need to know the exact version number
>> before installing and searching some files (environment script file,
>> etc). And the same releases of packages belong to different version
>> (just the build date is not in the same day) seems very strange and
>> hard to handle for us?  
>> 
> 
> I think Josh has laid down the base for multiple version SDK support.
> The only problem is: 
> 
> SDKPATH = "/opt/${DISTRO}/${DISTRO_VERSION}"
> 
> which obviously is not what we want. We need a similar variable like
> SDK_VERSION, which is incremented only when SDK team thinks there's a
> need for a new version release or 
> else it keeps same in the life cycle of current version.
> 
> Liping, could you try to come up a new variable for your purpose?

As Kevin mentioned, can we derive SDK_VERSION from DISTRO_VERSION so only
contains 0.9?
> 
> Thanks
> Kevin

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 8455 bytes --]

Re: version problems about SDK

[Joshua Lock]

On Sun, 2010-12-12 at 23:53 -0800, Zhang, Jessica wrote:
> Tian, Kevin wrote:
> >> From: Ke, Liping
> >> Sent: Monday, December 13, 2010 2:53 PM
> >> 
> >> Hi, Jessica & Josh
> >> 
> >> When we are trying to run installer script on lianhao's x86_64
> >> machine, we found if the images are build in two days, according to
> >> current version naming convention, some of the packages will be
> >> installed to /opt/poky/0.9+snapshot-20101210, some will be to
> >> /opt/poky/0.9+snapshot-20101210. 
> >> It will cause problem since we need to know the exact version number
> >> before installing and searching some files (environment script file,
> >> etc). And the same releases of packages belong to different version
> >> (just the build date is not in the same day) seems very strange and
> >> hard to handle for us?  
> >> 
> > 
> > I think Josh has laid down the base for multiple version SDK support.
> > The only problem is: 
> > 
> > SDKPATH = "/opt/${DISTRO}/${DISTRO_VERSION}"
> > 
> > which obviously is not what we want. We need a similar variable like
> > SDK_VERSION, which is incremented only when SDK team thinks there's a
> > need for a new version release or 
> > else it keeps same in the life cycle of current version.

I disagree, I think it's definitely useful to know which distribution
version your SDK is built against. In fact as the SDK components are
generated from the distro metadata introducing an extra variable seems a
little superfluous and just increases the number of things which need to
be changed for a release.

Also note the DATE element is only included in the DISTRO_VERSION for
development snapshots.

Cheers,
Joshua
-- 
Joshua Lock
        Intel Open Source Technology Centre

---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: version problems about SDK

[Tian, Kevin]

>From: Joshua Lock
>Sent: Monday, December 13, 2010 8:01 PM
>
>On Sun, 2010-12-12 at 23:53 -0800, Zhang, Jessica wrote:
>> Tian, Kevin wrote:
>> >> From: Ke, Liping
>> >> Sent: Monday, December 13, 2010 2:53 PM
>> >>
>> >> Hi, Jessica & Josh
>> >>
>> >> When we are trying to run installer script on lianhao's x86_64
>> >> machine, we found if the images are build in two days, according to
>> >> current version naming convention, some of the packages will be
>> >> installed to /opt/poky/0.9+snapshot-20101210, some will be to
>> >> /opt/poky/0.9+snapshot-20101210.
>> >> It will cause problem since we need to know the exact version number
>> >> before installing and searching some files (environment script file,
>> >> etc). And the same releases of packages belong to different version
>> >> (just the build date is not in the same day) seems very strange and
>> >> hard to handle for us?
>> >>
>> >
>> > I think Josh has laid down the base for multiple version SDK support.
>> > The only problem is:
>> >
>> > SDKPATH = "/opt/${DISTRO}/${DISTRO_VERSION}"
>> >
>> > which obviously is not what we want. We need a similar variable like
>> > SDK_VERSION, which is incremented only when SDK team thinks there's a
>> > need for a new version release or
>> > else it keeps same in the life cycle of current version.
>
>I disagree, I think it's definitely useful to know which distribution
>version your SDK is built against. In fact as the SDK components are
>generated from the distro metadata introducing an extra variable seems a
>little superfluous and just increases the number of things which need to
>be changed for a release.

Yes, SDK is generated from the distro metadata, which however doesn't prevent SDK
as a standalone component to have its own version variable. We can have:

SDK_VERSION = ${DISTRO_VERSION}

or, 

SDK_VERSION = ${DISTRO_VERSION}${SDK_REVISION}

or, 

SDK_VERSION = ...

I'm just a little bit worried to deduce SDK version from another variable (SDKPATH)
implicitly.

I agree that to have distribution version included will be informative, e.g in Android:
	"SDK platform Andriod 2.3, API 9, revision 1"

>
>Also note the DATE element is only included in the DISTRO_VERSION for
>development snapshots.
>

Good to know this info.

Thanks
Kevin

Re: version problems about SDK

[Zhang, Jessica]

[-- Attachment #1: Type: text/plain, Size: 2276 bytes --]

Joshua Lock wrote:
> On Sun, 2010-12-12 at 23:53 -0800, Zhang, Jessica wrote:
>> Tian, Kevin wrote:
>>>> From: Ke, Liping
>>>> Sent: Monday, December 13, 2010 2:53 PM
>>>> 
>>>> Hi, Jessica & Josh
>>>> 
>>>> When we are trying to run installer script on lianhao's x86_64
>>>> machine, we found if the images are build in two days, according to
>>>> current version naming convention, some of the packages will be
>>>> installed to /opt/poky/0.9+snapshot-20101210, some will be to
>>>> /opt/poky/0.9+snapshot-20101210.
>>>> It will cause problem since we need to know the exact version
>>>> number before installing and searching some files (environment
>>>> script file, etc). And the same releases of packages belong to
>>>> different version (just the build date is not in the same day)
>>>> seems very strange and hard to handle for us? 
>>>> 
>>> 
>>> I think Josh has laid down the base for multiple version SDK
>>> support. The only problem is: 
>>> 
>>> SDKPATH = "/opt/${DISTRO}/${DISTRO_VERSION}"
>>> 
>>> which obviously is not what we want. We need a similar variable like
>>> SDK_VERSION, which is incremented only when SDK team thinks there's
>>> a need for a new version release or
>>> else it keeps same in the life cycle of current version.
> 
> I disagree, I think it's definitely useful to know which distribution
> version your SDK is built against. In fact as the SDK components are
> generated from the distro metadata introducing an extra variable
> seems a little superfluous and just increases the number of things
> which need to be changed for a release.
> 
> Also note the DATE element is only included in the DISTRO_VERSION for
> development snapshots.
> 

Since the DATE element is only included in the DISTRO_VERSION for
development, then I'd suggest that our SDK_VERSION logic to be as:
If DISTRO_VERSION contains snapshot
SDK_VERSION = 0.9+snapshot (stripe off the date part)
Else
SDK_VERSION = DISTRO_VERSION (which means the DISTRO is a stablized and
meaningful version, e.g. M3_RC1, etc, or 1.0 relrease, etc.)

SDKPATH = "/opt/${DISTRO}/${SDK_VERSION}"

This way we can easily link the SDK_VERSION to DISTRO_VERSION and avoid the
unnecessary version issue during the development cycle...

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 8455 bytes --]