Cannot extract extended community from Cisco_IOS_XR_ipv4_bgp_oper in YDK 0.5.5

• Used a script to extract extended community in YDK version 0.5.2 and it was working fine. Now want to run the script again in version 0.5.5 and it suddenly stopped working. Maybe interesting to mention is that you can see from the xml output that it is receiving the community objects -the python YDK objects with no value.
• Also maybe interesting to mention is that if you PUT to crud read object the Network object Entity filter, need to iterate through Instance Entity object. Before in version 0.5.2/0.5.3 PUT to crud read network object was able to iterate through network object without problem.

Confirm which version of IOS-XR you are using. Also which version of the IOS-XR models you have installed (displayed by 'pip freeze'). This may be because in the version of XR you are using, the extended community content comes back as: 

<extended-community>0</extended-community>

<extended-community>2</extended-community>

<extended-community>96</extended-community>

<extended-community>138</extended-community>

<extended-community>0</extended-community>

<extended-community>0</extended-community>

<extended-community>39</extended-community>

<extended-community>26</extended-community>

<extended-community>0</extended-community>

<extended-community>2</extended-community>

<extended-community>96</extended-community>

<extended-community>138</extended-community>

<extended-community>0</extended-community>

<extended-community>0</extended-community>

<extended-community>39</extended-community>

<extended-community>29</extended-community>

 This is clearly a leaf-list in YANG terms, and consistent with, say IOS-XR 6.1.2's definition:

     leaf-list extended-community {

      type uint8;

      description "Extended community attribute";

    }

 ...but with invalid data, as a leaf-list may only contain unique values and your sample data contains multiple instances of 0 and 2 and other values. In IOS-XR 6.2.1 this definition was updated to be:

     list extended-community {

      description "Extended community attribute";

        leaf entry {

                  type uint8;

        }

    }

 ...which is what it should always have been. Thus the original behavior was a bug.

 Since the YDK-Py uses a specialized list class for leaf-lists, an exception would be raised if you had a version of the YDK-Py installed that is consistent with the older version of XR . Hence would suspect you are using 6.1.x  or maybe earlier.

 Thus suspect what is happening is that you have a YDK-Py aligned with the newer version of the model, and it is just not decoding the older format of the data.

• Details on your XR version and XR YDK-Py version will confirm this.
•  The devices are XRv in 6.1.2 version. This is the output of pip freeze:

 ydk==0.5.5

ydk-models-cisco-ios-xr==6.2.1

 Is there any plan or approach how to avoid such issues. When customer upgrade YDK and its models to new version although the devices will run on older version with older yang models.

We are looking at possibly renaming the generated YDK-Py instances such that the version name is in the name of the package. So, "ydk-models-cisco-ios-xr==6.2.1” may become "ydk-models-cisco-ios-xr-6.2.1==1.0.0”. This will allow clients to use a YDK-Py version consistent with the devices they are using.