)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":31245,"name":"Daniel Bengtsson","email":"dbengt@redhat.com","username":"damani42"},"change_message_id":"44c55f75c39223c16bef2b3482630a179c14b167","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"96367a71_a9f0a486","updated":"2024-08-01 09:31:16.000000000","message":"What is the status here?","commit_id":"40cd5da175454fa7d1da2ee55b2cebb74cb8eb52"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"514767e1aa311a68862bd6c5891147c88ac348a2","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"3f5468f5_fb761f6e","updated":"2024-08-01 10:11:43.000000000","message":"while jan is still working with openstack in there new job they have nto been workign upstream for several years now.\n\nthe content an reasearch they did is still correct from my understanding so it would be ideal if someone of the oslo core team could get this over the line.\n\nit woudl proably be workth merging this as is to not loose the work and spread the knowledge and then follow ups can be done separately to improve it when people have time\n\ncapturing this tribal knowledge even if its not perfect is better then abandoning this.","commit_id":"40cd5da175454fa7d1da2ee55b2cebb74cb8eb52"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"18231e69674538a9e5a3bb042603f05330bb7b22","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"743b75d2_372b7d84","in_reply_to":"3f5468f5_fb761f6e","updated":"2026-04-17 11:00:49.000000000","message":"Done","commit_id":"40cd5da175454fa7d1da2ee55b2cebb74cb8eb52"}],"doc/source/user/versioning.rst":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"a024bcf91011bbfd9c3a14018f93962f02f68376","unresolved":true,"context_lines":[{"line_number":19,"context_line":"* The object model is not designed to be extensible by a third party."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"* The object model assumes that the module serialising the object will always"},{"line_number":22,"context_line":"  backlevel the object to an older version."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"This tutorial illustrates how to extend the"},{"line_number":25,"context_line":":meth:`oslo_versionedobjects.base.VersionedObject.obj_make_compatible` method"}],"source_content_type":"text/x-rst","patch_set":3,"id":"0e682b53_0b152213","line":22,"updated":"2026-04-14 21:04:05.000000000","message":"Do you mean \"is capable of backleveling the object to an older version\"? If so, I think that would be better. In Nova, for example, a separate service does the backleveling for the services that might need it. Using the object (model) of course, but your statement sort of reads like the object does this automatically (to me).\n\nAlso, we have plenty of situations where this is not possible. The object implementation always intends to be able to backlevel, but sometimes it\u0027s not possible. If a field has been added that can\u0027t reasonably be removed or converted into the older version\u0027s format (like a field had a possible value added), we will raise an error. Perhaps this is too detailed/specific for your doc here, but I just thought I\u0027d bring it up.","commit_id":"5e5a76881ea07d96dc88ce48fc1d71cfc21aec2e"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"fa2a42153b7518f3089fb63617bebb36ca49e56d","unresolved":true,"context_lines":[{"line_number":19,"context_line":"* The object model is not designed to be extensible by a third party."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"* The object model assumes that the module serialising the object will always"},{"line_number":22,"context_line":"  backlevel the object to an older version."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"This tutorial illustrates how to extend the"},{"line_number":25,"context_line":":meth:`oslo_versionedobjects.base.VersionedObject.obj_make_compatible` method"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fd51adca_882f6d78","line":22,"in_reply_to":"0e682b53_0b152213","updated":"2026-04-15 14:45:35.000000000","message":"Not Jan, but this makes sense. I can rework","commit_id":"5e5a76881ea07d96dc88ce48fc1d71cfc21aec2e"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"18231e69674538a9e5a3bb042603f05330bb7b22","unresolved":false,"context_lines":[{"line_number":19,"context_line":"* The object model is not designed to be extensible by a third party."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"* The object model assumes that the module serialising the object will always"},{"line_number":22,"context_line":"  backlevel the object to an older version."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"This tutorial illustrates how to extend the"},{"line_number":25,"context_line":":meth:`oslo_versionedobjects.base.VersionedObject.obj_make_compatible` method"}],"source_content_type":"text/x-rst","patch_set":3,"id":"483cef27_993ffd1d","line":22,"in_reply_to":"fd51adca_882f6d78","updated":"2026-04-17 11:00:49.000000000","message":"Done","commit_id":"5e5a76881ea07d96dc88ce48fc1d71cfc21aec2e"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"a024bcf91011bbfd9c3a14018f93962f02f68376","unresolved":true,"context_lines":[{"line_number":28,"context_line":""},{"line_number":29,"context_line":".. note:: This tutorial covers fields only. Adding and extending methods"},{"line_number":30,"context_line":"          follow similar rules, but guidelines for the general case is"},{"line_number":31,"context_line":"          not tractable."},{"line_number":32,"context_line":""},{"line_number":33,"context_line":"Reference patterns for constructing the ``obj_make_compatible()`` method and"},{"line_number":34,"context_line":"``obj_relationships`` field in an evolving object model is provided:"}],"source_content_type":"text/x-rst","patch_set":3,"id":"974a01d7_90e3f5b5","line":31,"updated":"2026-04-14 21:04:05.000000000","message":"Similar rules for additive behavior, but there\u0027s no `obj_make_compatible()` interaction with methods.","commit_id":"5e5a76881ea07d96dc88ce48fc1d71cfc21aec2e"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"18231e69674538a9e5a3bb042603f05330bb7b22","unresolved":false,"context_lines":[{"line_number":28,"context_line":""},{"line_number":29,"context_line":".. note:: This tutorial covers fields only. Adding and extending methods"},{"line_number":30,"context_line":"          follow similar rules, but guidelines for the general case is"},{"line_number":31,"context_line":"          not tractable."},{"line_number":32,"context_line":""},{"line_number":33,"context_line":"Reference patterns for constructing the ``obj_make_compatible()`` method and"},{"line_number":34,"context_line":"``obj_relationships`` field in an evolving object model is provided:"}],"source_content_type":"text/x-rst","patch_set":3,"id":"e266dba4_2fbbbaf5","line":31,"in_reply_to":"974a01d7_90e3f5b5","updated":"2026-04-17 11:00:49.000000000","message":"Done","commit_id":"5e5a76881ea07d96dc88ce48fc1d71cfc21aec2e"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"a024bcf91011bbfd9c3a14018f93962f02f68376","unresolved":true,"context_lines":[{"line_number":41,"context_line":""},{"line_number":42,"context_line":"* When classes are related to others by composition:"},{"line_number":43,"context_line":""},{"line_number":44,"context_line":"  * The ``obj_relationships`` field of the owning class has to be updated."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"  * Depending on the model, the contained classes have to increase their"},{"line_number":47,"context_line":"    version in lockstep."}],"source_content_type":"text/x-rst","patch_set":3,"id":"6e893e6f_3070e79a","line":44,"updated":"2026-04-14 21:04:05.000000000","message":"It\u0027s been so long since I wrote this stuff that my memory is a bit fuzzy. However, this is not accurate. We don\u0027t maintain _any_ relationships by hand in nova anymore. The act of backporting across services passes a manifest of all the object versions known by the requester, which the backporting service uses to create the relationships automatically.","commit_id":"5e5a76881ea07d96dc88ce48fc1d71cfc21aec2e"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"fa2a42153b7518f3089fb63617bebb36ca49e56d","unresolved":true,"context_lines":[{"line_number":41,"context_line":""},{"line_number":42,"context_line":"* When classes are related to others by composition:"},{"line_number":43,"context_line":""},{"line_number":44,"context_line":"  * The ``obj_relationships`` field of the owning class has to be updated."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"  * Depending on the model, the contained classes have to increase their"},{"line_number":47,"context_line":"    version in lockstep."}],"source_content_type":"text/x-rst","patch_set":3,"id":"7102d43c_03218e55","line":44,"in_reply_to":"6e893e6f_3070e79a","updated":"2026-04-15 14:45:35.000000000","message":"Note that I pushed a follow-up to this [as a separate change](https://review.opendev.org/c/openstack/oslo.versionedobjects/+/984586/2/doc/source/user/versioning.rst) since I didn\u0027t want to confuse authorship of this change, and that follow-up updates a lot of the verbiage here. It\u0027s probably too difficult to review them separately via Gerrit, so would you prefer if I folded it in here instead?","commit_id":"5e5a76881ea07d96dc88ce48fc1d71cfc21aec2e"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"18231e69674538a9e5a3bb042603f05330bb7b22","unresolved":false,"context_lines":[{"line_number":41,"context_line":""},{"line_number":42,"context_line":"* When classes are related to others by composition:"},{"line_number":43,"context_line":""},{"line_number":44,"context_line":"  * The ``obj_relationships`` field of the owning class has to be updated."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"  * Depending on the model, the contained classes have to increase their"},{"line_number":47,"context_line":"    version in lockstep."}],"source_content_type":"text/x-rst","patch_set":3,"id":"e3cc538e_64b3190a","line":44,"in_reply_to":"7102d43c_03218e55","updated":"2026-04-17 11:00:49.000000000","message":"Done","commit_id":"5e5a76881ea07d96dc88ce48fc1d71cfc21aec2e"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"a024bcf91011bbfd9c3a14018f93962f02f68376","unresolved":true,"context_lines":[{"line_number":167,"context_line":"When an class is extended by composition, the"},{"line_number":168,"context_line":":attr:`oslo_versionedobjects.base.VersionedObject.obj_relationships` field must"},{"line_number":169,"context_line":"be overridden in the owning class with a map translating the owning class\u0027s"},{"line_number":170,"context_line":"versions to the contained class\u0027s versions."},{"line_number":171,"context_line":""},{"line_number":172,"context_line":".. note:: Since the ``physics_model`` field allows inherited objects, and the"},{"line_number":173,"context_line":"          ``obj_relationships`` field contains a simple version map, the object"}],"source_content_type":"text/x-rst","patch_set":3,"id":"455b6e70_72768bb4","line":170,"updated":"2026-04-14 21:04:05.000000000","message":"As above, this is not a thing. Note there are no manually-maintained obj_relationships in all of nova anymore. There must be some reason this is perceived to be required?","commit_id":"5e5a76881ea07d96dc88ce48fc1d71cfc21aec2e"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"fa2a42153b7518f3089fb63617bebb36ca49e56d","unresolved":false,"context_lines":[{"line_number":167,"context_line":"When an class is extended by composition, the"},{"line_number":168,"context_line":":attr:`oslo_versionedobjects.base.VersionedObject.obj_relationships` field must"},{"line_number":169,"context_line":"be overridden in the owning class with a map translating the owning class\u0027s"},{"line_number":170,"context_line":"versions to the contained class\u0027s versions."},{"line_number":171,"context_line":""},{"line_number":172,"context_line":".. note:: Since the ``physics_model`` field allows inherited objects, and the"},{"line_number":173,"context_line":"          ``obj_relationships`` field contains a simple version map, the object"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3006cf02_a6da02fe","line":170,"in_reply_to":"455b6e70_72768bb4","updated":"2026-04-15 14:45:35.000000000","message":"Agreed. I addressed this in the follow-up\n\nhttps://review.opendev.org/c/openstack/oslo.versionedobjects/+/984586/2/doc/source/user/versioning.rst","commit_id":"5e5a76881ea07d96dc88ce48fc1d71cfc21aec2e"}],"doc/source/user/versioning_tutorial.rst":[{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"049027f6033a0b5056d04860737966cca4edb5ef","unresolved":false,"context_lines":[{"line_number":224,"context_line":"   versioned in lockstep because of the composition relationship with the"},{"line_number":225,"context_line":"   ``Beta`` class."},{"line_number":226,"context_line":""},{"line_number":227,"context_line":"#. The ``Beta`` class has to increase its version in order to consume the"},{"line_number":228,"context_line":"   newer versions of the ``PhysicsModel`` hierarchy. The ``obj_relationships``"},{"line_number":229,"context_line":"   map reflects that version 1.5 of the ``Beta`` class understand version 1.1"},{"line_number":230,"context_line":"   objects interiting from ``PhysicsModel``."},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"Summary"},{"line_number":233,"context_line":"-------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_8692cef5","line":230,"range":{"start_line":227,"start_character":0,"end_line":230,"end_character":44},"updated":"2019-01-22 17:18:04.000000000","message":"I thought this was no longer necessary. I\u0027m not sure why, but iirc we have long since stopped updating parent versions when a child is updated","commit_id":"40cd5da175454fa7d1da2ee55b2cebb74cb8eb52"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"205b993e8e54e83db4280db8da5178b31fc332a5","unresolved":false,"context_lines":[{"line_number":224,"context_line":"   versioned in lockstep because of the composition relationship with the"},{"line_number":225,"context_line":"   ``Beta`` class."},{"line_number":226,"context_line":""},{"line_number":227,"context_line":"#. The ``Beta`` class has to increase its version in order to consume the"},{"line_number":228,"context_line":"   newer versions of the ``PhysicsModel`` hierarchy. The ``obj_relationships``"},{"line_number":229,"context_line":"   map reflects that version 1.5 of the ``Beta`` class understand version 1.1"},{"line_number":230,"context_line":"   objects interiting from ``PhysicsModel``."},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"Summary"},{"line_number":233,"context_line":"-------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_c9031e0d","line":230,"range":{"start_line":227,"start_character":0,"end_line":230,"end_character":44},"in_reply_to":"5fc1f717_2e550851","updated":"2019-03-06 18:46:33.000000000","message":"Sweet, thanks!","commit_id":"40cd5da175454fa7d1da2ee55b2cebb74cb8eb52"},{"author":{"_account_id":25733,"name":"Jan Gutter","email":"github@jangutter.com","username":"jangutter"},"change_message_id":"7f56b0f3b9a3b4721735bc608780b5e48cf889d9","unresolved":false,"context_lines":[{"line_number":224,"context_line":"   versioned in lockstep because of the composition relationship with the"},{"line_number":225,"context_line":"   ``Beta`` class."},{"line_number":226,"context_line":""},{"line_number":227,"context_line":"#. The ``Beta`` class has to increase its version in order to consume the"},{"line_number":228,"context_line":"   newer versions of the ``PhysicsModel`` hierarchy. The ``obj_relationships``"},{"line_number":229,"context_line":"   map reflects that version 1.5 of the ``Beta`` class understand version 1.1"},{"line_number":230,"context_line":"   objects interiting from ``PhysicsModel``."},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"Summary"},{"line_number":233,"context_line":"-------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_2e550851","line":230,"range":{"start_line":227,"start_character":0,"end_line":230,"end_character":44},"in_reply_to":"5fc1f717_b894e2e9","updated":"2019-03-06 18:38:12.000000000","message":"Thanks for clearing this up:\n\nYes, I understand that obj_relationships is to be used for \"composition\" only. I think at this point I had run a bit out of steam, so this explains the poor explanation.\n\nI\u0027ll see if it\u0027s simple to rework the examples, but I\u0027ll definitely point out obj_relationships is something to be avoided and manifests are used in practice.","commit_id":"40cd5da175454fa7d1da2ee55b2cebb74cb8eb52"},{"author":{"_account_id":25733,"name":"Jan Gutter","email":"github@jangutter.com","username":"jangutter"},"change_message_id":"2d6b8ce60fffd67bea5cd678ba5a9f5d9b29532e","unresolved":false,"context_lines":[{"line_number":224,"context_line":"   versioned in lockstep because of the composition relationship with the"},{"line_number":225,"context_line":"   ``Beta`` class."},{"line_number":226,"context_line":""},{"line_number":227,"context_line":"#. The ``Beta`` class has to increase its version in order to consume the"},{"line_number":228,"context_line":"   newer versions of the ``PhysicsModel`` hierarchy. The ``obj_relationships``"},{"line_number":229,"context_line":"   map reflects that version 1.5 of the ``Beta`` class understand version 1.1"},{"line_number":230,"context_line":"   objects interiting from ``PhysicsModel``."},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"Summary"},{"line_number":233,"context_line":"-------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_c60d363f","line":230,"range":{"start_line":227,"start_character":0,"end_line":230,"end_character":44},"in_reply_to":"9fdfeff1_8692cef5","updated":"2019-01-22 17:27:17.000000000","message":"Yeah, I was wondering about that too. The trick is that the obj_relationships field _has_ to be updated. I\u0027m not sure if that touched the object hash or not - one more thing to test and verify.\n\nOne more clarification: this is not a parent / child relationship that changed in this case, it\u0027s an owned / contained relationship.","commit_id":"40cd5da175454fa7d1da2ee55b2cebb74cb8eb52"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"65fa4ea31e68e6a7d7f1cd8b08b6c9945ef68ea7","unresolved":false,"context_lines":[{"line_number":224,"context_line":"   versioned in lockstep because of the composition relationship with the"},{"line_number":225,"context_line":"   ``Beta`` class."},{"line_number":226,"context_line":""},{"line_number":227,"context_line":"#. The ``Beta`` class has to increase its version in order to consume the"},{"line_number":228,"context_line":"   newer versions of the ``PhysicsModel`` hierarchy. The ``obj_relationships``"},{"line_number":229,"context_line":"   map reflects that version 1.5 of the ``Beta`` class understand version 1.1"},{"line_number":230,"context_line":"   objects interiting from ``PhysicsModel``."},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"Summary"},{"line_number":233,"context_line":"-------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_b894e2e9","line":230,"range":{"start_line":227,"start_character":0,"end_line":230,"end_character":44},"in_reply_to":"9fdfeff1_b8c5863e","updated":"2019-03-06 17:15:30.000000000","message":"Yeah, so obj_relationships is not for subclasses, but for nested objects stored inside an object (i.e. an Object field of a different type). _That_ behavior is no longer necessary because of the manifest stuff we have.\n\nNow, there may be some accidental effects of the legacy obj_relationships stuff (which we had hoped to remove some day) that \"helps\" you here, if that\u0027s what you\u0027re implying, but it\u0027s entirely unintentional. I think it would be better to remove the obj_relationships mention from here (except for any case where you mention it\u0027s old and shouldn\u0027t be used for new code). If there\u0027s really a requirement for bumping the child class along with the parent, I think you just need to tell people to be careful and not imply or state that we have actual code to handle that.","commit_id":"40cd5da175454fa7d1da2ee55b2cebb74cb8eb52"},{"author":{"_account_id":25733,"name":"Jan Gutter","email":"github@jangutter.com","username":"jangutter"},"change_message_id":"8e243ca994fe37a5e7e678461f668aa19a260155","unresolved":false,"context_lines":[{"line_number":224,"context_line":"   versioned in lockstep because of the composition relationship with the"},{"line_number":225,"context_line":"   ``Beta`` class."},{"line_number":226,"context_line":""},{"line_number":227,"context_line":"#. The ``Beta`` class has to increase its version in order to consume the"},{"line_number":228,"context_line":"   newer versions of the ``PhysicsModel`` hierarchy. The ``obj_relationships``"},{"line_number":229,"context_line":"   map reflects that version 1.5 of the ``Beta`` class understand version 1.1"},{"line_number":230,"context_line":"   objects interiting from ``PhysicsModel``."},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"Summary"},{"line_number":233,"context_line":"-------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_b8c5863e","line":230,"range":{"start_line":227,"start_character":0,"end_line":230,"end_character":44},"in_reply_to":"9fdfeff1_c60d363f","updated":"2019-01-24 11:57:23.000000000","message":"OK, I think it turns out to be pretty important to version bump here _if_ you want to have deterministic serialization.\n\nFor example, you did not version bump Beta, Day 7 would serialize the \u0027physics_model\u0027 field to version 1.0 for Beta version 1.4. Day 8 would serialize the field to version 1.1. Version bumping the owner (or container) class is a guaranteed way to be absolutely certain that a Day 8 object creator can pass the object to a Day 7 consumer where the creator has absolute control about the fields and how the object is backleveled.","commit_id":"40cd5da175454fa7d1da2ee55b2cebb74cb8eb52"},{"author":{"_account_id":25733,"name":"Jan Gutter","email":"github@jangutter.com","username":"jangutter"},"change_message_id":"8e243ca994fe37a5e7e678461f668aa19a260155","unresolved":false,"context_lines":[{"line_number":250,"context_line":""},{"line_number":251,"context_line":"    0. use versionutils to calculate target_version"},{"line_number":252,"context_line":""},{"line_number":253,"context_line":"    1. Remove added members from the primitive in reverse order:"},{"line_number":254,"context_line":"       - if target_version \u003c (1, 5) and \u0027member_one_five\u0027 in primitive:"},{"line_number":255,"context_line":"             del primitive[\u0027member_one_five\u0027]"},{"line_number":256,"context_line":"       - if target_version \u003c (1, 3) and \u0027member_one_three\u0027 in primitive:"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_5b7014dd","line":253,"range":{"start_line":253,"start_character":7,"end_line":253,"end_character":63},"updated":"2019-01-24 11:57:23.000000000","message":"bikeshed: I kinda like reverse ordering here, since it looks like C unwinding.","commit_id":"40cd5da175454fa7d1da2ee55b2cebb74cb8eb52"},{"author":{"_account_id":25733,"name":"Jan Gutter","email":"github@jangutter.com","username":"jangutter"},"change_message_id":"8e243ca994fe37a5e7e678461f668aa19a260155","unresolved":false,"context_lines":[{"line_number":252,"context_line":""},{"line_number":253,"context_line":"    1. Remove added members from the primitive in reverse order:"},{"line_number":254,"context_line":"       - if target_version \u003c (1, 5) and \u0027member_one_five\u0027 in primitive:"},{"line_number":255,"context_line":"             del primitive[\u0027member_one_five\u0027]"},{"line_number":256,"context_line":"       - if target_version \u003c (1, 3) and \u0027member_one_three\u0027 in primitive:"},{"line_number":257,"context_line":"             del primitive[\u0027member_one_three\u0027]"},{"line_number":258,"context_line":"       - if target_version \u003c (1, 1) and \u0027member_one_one\u0027 in primitive:"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_3b46707e","line":255,"range":{"start_line":255,"start_character":13,"end_line":255,"end_character":45},"updated":"2019-01-24 11:57:23.000000000","message":"bikeshed: Alternatively primitive.pop(\u0027member_one_five\u0027, None)","commit_id":"40cd5da175454fa7d1da2ee55b2cebb74cb8eb52"},{"author":{"_account_id":25733,"name":"Jan Gutter","email":"github@jangutter.com","username":"jangutter"},"change_message_id":"8e243ca994fe37a5e7e678461f668aa19a260155","unresolved":false,"context_lines":[{"line_number":258,"context_line":"       - if target_version \u003c (1, 1) and \u0027member_one_one\u0027 in primitive:"},{"line_number":259,"context_line":"             del primitive[\u0027member_one_one\u0027]"},{"line_number":260,"context_line":""},{"line_number":261,"context_line":"    2. Call the parent method explicitly when the parent class caused a version"},{"line_number":262,"context_line":"       bump in this object, in the following if/elif tree:"},{"line_number":263,"context_line":"       - if target_version \u003c (1, 2):"},{"line_number":264,"context_line":"             super(MyClass, self).obj_make_compatible(primitive, \u00271.0\u0027)"},{"line_number":265,"context_line":"       - elif target_version \u003c (1, 4):"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_db540424","line":262,"range":{"start_line":261,"start_character":7,"end_line":262,"end_character":57},"updated":"2019-01-24 11:57:23.000000000","message":"bikeshed: the if/elif/else tree here makes diffs a little smaller, but only works if it\u0027s done in forward order.","commit_id":"40cd5da175454fa7d1da2ee55b2cebb74cb8eb52"},{"author":{"_account_id":25733,"name":"Jan Gutter","email":"github@jangutter.com","username":"jangutter"},"change_message_id":"8e243ca994fe37a5e7e678461f668aa19a260155","unresolved":false,"context_lines":[{"line_number":268,"context_line":"    3. Finally, if target_version is recent enough, call the parent method with"},{"line_number":269,"context_line":"       the current version of the parent class:"},{"line_number":270,"context_line":"       - else:"},{"line_number":271,"context_line":"             super(MyClass, self).obj_make_compatible(primitive, \u00271.2\u0027)"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_fb2468c8","line":271,"updated":"2019-01-24 11:57:23.000000000","message":"I\u0027m planning to add FAQ\u0027s here, like:\n1. What are the guarantees: \"The creator of an object using Day X code, can backlevel it to a version acceptable for a Day 1 to X consumer.\"\n2. You don\u0027t have to follow this, but if you don\u0027t you might need to add logic to your consumers to accept future versions.\n\nAlso, in a follow-on, I plan to highlight the changed lines between each day.","commit_id":"40cd5da175454fa7d1da2ee55b2cebb74cb8eb52"}],"oslo_versionedobjects/base.py":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"a024bcf91011bbfd9c3a14018f93962f02f68376","unresolved":true,"context_lines":[{"line_number":402,"context_line":"    #: element is reserved for stable branch backports. The ``.Z`` is ignored"},{"line_number":403,"context_line":"    #: for the purposes of triggering a backport, which means anything changed"},{"line_number":404,"context_line":"    #: under a ``.Z`` must be additive and non-destructive such that a node"},{"line_number":405,"context_line":"    #: that knows about ``X.Y`` can consider ``X.Y.Z`` equivalent."},{"line_number":406,"context_line":"    VERSION: str \u003d \u00271.0\u0027"},{"line_number":407,"context_line":""},{"line_number":408,"context_line":"    #: Object namespace for serialization"}],"source_content_type":"text/x-python","patch_set":3,"id":"66017d37_61040b79","line":405,"updated":"2026-04-14 21:04:05.000000000","message":"Do we really need to rewrite all these lines to prefix them with colon? From a quick skim it looks like almost nothing is changing yet it will make these all look like they\u0027re from 2026 in the git history.","commit_id":"5e5a76881ea07d96dc88ce48fc1d71cfc21aec2e"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"fa2a42153b7518f3089fb63617bebb36ca49e56d","unresolved":true,"context_lines":[{"line_number":402,"context_line":"    #: element is reserved for stable branch backports. The ``.Z`` is ignored"},{"line_number":403,"context_line":"    #: for the purposes of triggering a backport, which means anything changed"},{"line_number":404,"context_line":"    #: under a ``.Z`` must be additive and non-destructive such that a node"},{"line_number":405,"context_line":"    #: that knows about ``X.Y`` can consider ``X.Y.Z`` equivalent."},{"line_number":406,"context_line":"    VERSION: str \u003d \u00271.0\u0027"},{"line_number":407,"context_line":""},{"line_number":408,"context_line":"    #: Object namespace for serialization"}],"source_content_type":"text/x-python","patch_set":3,"id":"9b1ffd45_1239bfaa","line":405,"in_reply_to":"66017d37_61040b79","updated":"2026-04-15 14:45:35.000000000","message":"Again, not Jan, but this causes them to be picked up by Sphinx for api docs. Compare the results from [the most recent CI run](https://fcd003cab3aab07c2e4f-3105dcd3f53910544ad4af58357c5c48.ssl.cf5.rackcdn.com/openstack/b8827b205fbf46d4bd6a3e2401c94962/docs/reference/base.html) to [our current docs](https://docs.openstack.org/oslo.versionedobjects/latest/reference/base.html) and search for e.g. `OBJ_SERIAL_NAMESPACE`.\n\nWould it help if this was dragged out to a separate precursor change? That could be ignored via `.git-blame-ignore-revs` if needed (though I personally tend to just iterate through `git blame` (`git blame`, `git blame \u003ccommit-i-want-to-ignore\u003e~`, `git blame \u003canother-commit-i-want-to-ignore\u003e~`, ...)","commit_id":"5e5a76881ea07d96dc88ce48fc1d71cfc21aec2e"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"18231e69674538a9e5a3bb042603f05330bb7b22","unresolved":false,"context_lines":[{"line_number":402,"context_line":"    #: element is reserved for stable branch backports. The ``.Z`` is ignored"},{"line_number":403,"context_line":"    #: for the purposes of triggering a backport, which means anything changed"},{"line_number":404,"context_line":"    #: under a ``.Z`` must be additive and non-destructive such that a node"},{"line_number":405,"context_line":"    #: that knows about ``X.Y`` can consider ``X.Y.Z`` equivalent."},{"line_number":406,"context_line":"    VERSION: str \u003d \u00271.0\u0027"},{"line_number":407,"context_line":""},{"line_number":408,"context_line":"    #: Object namespace for serialization"}],"source_content_type":"text/x-python","patch_set":3,"id":"4ce55beb_0c99ef6f","line":405,"in_reply_to":"9b1ffd45_1239bfaa","updated":"2026-04-17 11:00:49.000000000","message":"I moved this to a separate commit.","commit_id":"5e5a76881ea07d96dc88ce48fc1d71cfc21aec2e"}],"oslo_versionedobjects/examples/versioning_day1.py":[{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"049027f6033a0b5056d04860737966cca4edb5ef","unresolved":false,"context_lines":[{"line_number":18,"context_line":""},{"line_number":19,"context_line":"@base.VersionedObjectRegistry.register"},{"line_number":20,"context_line":"class Alpha(base.VersionedObject):"},{"line_number":21,"context_line":"    \"\"\"Represents a fundamendal class in our object model\"\"\""},{"line_number":22,"context_line":""},{"line_number":23,"context_line":"    #: Class version history"},{"line_number":24,"context_line":"    #:"}],"source_content_type":"text/x-python","patch_set":1,"id":"9fdfeff1_6667aa4f","line":21,"range":{"start_line":21,"start_character":20,"end_line":21,"end_character":31},"updated":"2019-01-22 17:18:04.000000000","message":"fundamental","commit_id":"40cd5da175454fa7d1da2ee55b2cebb74cb8eb52"},{"author":{"_account_id":25733,"name":"Jan Gutter","email":"github@jangutter.com","username":"jangutter"},"change_message_id":"2d6b8ce60fffd67bea5cd678ba5a9f5d9b29532e","unresolved":false,"context_lines":[{"line_number":18,"context_line":""},{"line_number":19,"context_line":"@base.VersionedObjectRegistry.register"},{"line_number":20,"context_line":"class Alpha(base.VersionedObject):"},{"line_number":21,"context_line":"    \"\"\"Represents a fundamendal class in our object model\"\"\""},{"line_number":22,"context_line":""},{"line_number":23,"context_line":"    #: Class version history"},{"line_number":24,"context_line":"    #:"}],"source_content_type":"text/x-python","patch_set":1,"id":"9fdfeff1_d1388ed4","line":21,"range":{"start_line":21,"start_character":20,"end_line":21,"end_character":31},"in_reply_to":"9fdfeff1_6667aa4f","updated":"2019-01-22 17:27:17.000000000","message":"Gonna have to sed that one globally :-p","commit_id":"40cd5da175454fa7d1da2ee55b2cebb74cb8eb52"}],"oslo_versionedobjects/examples/versioning_day6.py":[{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a8a6e1c750d2f76f193c8f2b3bf58338c218302d","unresolved":false,"context_lines":[{"line_number":128,"context_line":"    }"},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"    obj_relationships \u003d {"},{"line_number":131,"context_line":"        \u0027physics_model\u0027: ((\u00271.2\u0027, \u00271.0\u0027),),"},{"line_number":132,"context_line":"    }"},{"line_number":133,"context_line":""},{"line_number":134,"context_line":"    def obj_make_compatible(self, primitive, target_version):"}],"source_content_type":"text/x-python","patch_set":1,"id":"9fdfeff1_a3734415","line":131,"range":{"start_line":131,"start_character":7,"end_line":131,"end_character":43},"updated":"2019-01-22 16:38:55.000000000","message":"do you need to add (\"1.3\",\"1.0\") here also.\ne.g. \n((\u00271.2\u0027, \u00271.0\u0027),(\"1.3\",\"1.0\")),\nso that both 1.2 and 1.3 map to 1.0 of the composed physics model.\n\nthe edcase im thinking of is \nif i have the beta v1.5 object with a 1.1 phyical model\nand i back level the beta object to 1.3 will this currently back level the phyics model to 1.0 as we would expect.","commit_id":"40cd5da175454fa7d1da2ee55b2cebb74cb8eb52"},{"author":{"_account_id":25733,"name":"Jan Gutter","email":"github@jangutter.com","username":"jangutter"},"change_message_id":"b67f99a1100ac8fa953186fac35d2af8426a134f","unresolved":false,"context_lines":[{"line_number":128,"context_line":"    }"},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"    obj_relationships \u003d {"},{"line_number":131,"context_line":"        \u0027physics_model\u0027: ((\u00271.2\u0027, \u00271.0\u0027),),"},{"line_number":132,"context_line":"    }"},{"line_number":133,"context_line":""},{"line_number":134,"context_line":"    def obj_make_compatible(self, primitive, target_version):"}],"source_content_type":"text/x-python","patch_set":1,"id":"9fdfeff1_06701ea5","line":131,"range":{"start_line":131,"start_character":7,"end_line":131,"end_character":43},"in_reply_to":"9fdfeff1_a3734415","updated":"2019-01-22 16:54:20.000000000","message":"If I read the docs correctly:\n\n[(1.2, 1.0)]\n\nThis implies that all Beta objects, targeting version 1.2 and higher will backlevel the \u0027physics_model\u0027 field to 1.0. If they target version a version lower, the \u0027physics_model\u0027 field should be deleted.\n\n[(1.2, 1.0), (1.5, 1.1)]\n\nThis implies that Beta objects targeting version 1.5 and higher will backlevel \u0027physics_model\u0027 to 1.1. Beta objects targeting versions less than 1.5, but 1.2 or greater, will backlevel to 1.0. Objects targeting lower than 1.2 will not have \u0027physics_model\u0027.\n\nAnother useful thing would be to illustrate how to unit test this, but that\u0027s another ball of wax.","commit_id":"40cd5da175454fa7d1da2ee55b2cebb74cb8eb52"}],"oslo_versionedobjects/examples/versioning_day8.py":[{"author":{"_account_id":25733,"name":"Jan Gutter","email":"github@jangutter.com","username":"jangutter"},"change_message_id":"8e243ca994fe37a5e7e678461f668aa19a260155","unresolved":false,"context_lines":[{"line_number":167,"context_line":"    }"},{"line_number":168,"context_line":""},{"line_number":169,"context_line":"    obj_relationships \u003d {"},{"line_number":170,"context_line":"        \u0027physics_model\u0027: ((\u00271.2\u0027, \u00271.0\u0027), (\u00271.5\u0027, \u00271.1\u0027),),"},{"line_number":171,"context_line":"    }"},{"line_number":172,"context_line":""},{"line_number":173,"context_line":"    def obj_make_compatible(self, primitive, target_version):"}],"source_content_type":"text/x-python","patch_set":1,"id":"9fdfeff1_db29649b","line":170,"range":{"start_line":170,"start_character":25,"end_line":170,"end_character":59},"updated":"2019-01-24 11:57:23.000000000","message":"bikeshed: This could also be [(\u00271.2\u0027, 1.0\u0027), (\u00271.5\u0027, \u00271.1\u0027)]","commit_id":"40cd5da175454fa7d1da2ee55b2cebb74cb8eb52"}]}