)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"84f154bed8f4f5cf07b32b16aac03fbc086dfffe","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"ff2e9daa_289d0189","updated":"2025-04-02 17:54:00.000000000","message":"agree, if projects require specific version to pin that is doable in their rquirements.txt","commit_id":"8ee5c9fecedfe41843f81604597f9873ce70430b"},{"author":{"_account_id":12898,"name":"Tony Breeds","email":"tony@bakeyournoodle.com","username":"tonyb"},"change_message_id":"ab13679c2bf720c85b5a52e4015b416778b14d1e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"bdc247d5_635efde5","updated":"2025-04-02 22:29:12.000000000","message":"A couple of things.\n\n1) To avoid merge conflicts I suggest only modfying denylist.txt.  Yes this will leave os-traits in upper-constraints.txt but only until the bot change to synchronise things lands.  Famous last words but I don\u0027t think that\u0027ll be a big problem.\n\n2) What is \u0027otu-traits\u0027?  does the \u0027otu\u0027 mean something I\u0027m missing?\n\nI\u0027m +2 on this, but would like someone from the release team to verify that just removing os-traits from upper-constraints.txt is enough to stop post-release jobs from creating changes like [1].  Until then I\u0027m setting my vote to +1 (not that it really matters as we need a rebase/update anyway)\n\n\n[1] https://review.opendev.org/c/openstack/requirements/+/946181","commit_id":"9cd78f9546e7e3ce1b0217d9a2be9808fdf480b8"},{"author":{"_account_id":12898,"name":"Tony Breeds","email":"tony@bakeyournoodle.com","username":"tonyb"},"change_message_id":"6d37a34b1972d6721ca15aa98481c08f597bd242","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"31620c33_c026dce6","updated":"2025-04-05 06:29:40.000000000","message":"Dan, please\n1) re-base this change\n2) remove the u-c portion\n3) Add a comment in the commit message explaining that we\u0027re happy to let the bot clean up u-c after the fact\n\nI\u0027ll add an additional patch to add a warning in denylist.  I\u0027d ask you to do it but I\"m not sure exactly what to say other than \"os-traits is special; you aren\u0027t\" ... but nicer\n\nI Also want to make a couple of things clear.\n\n1) I am not discounting frickler\u0027s concerns.  I\u0027m possibly less worried\n2) I\u0027m only one core reviewer and wont do anything special to land this if other cores feel differently\n3) Dan, Sean and I all work for the same company but that is not a factor my decision making process.\n\nThat is all.","commit_id":"9cd78f9546e7e3ce1b0217d9a2be9808fdf480b8"},{"author":{"_account_id":13252,"name":"Dr. Jens Harbott","display_name":"Jens Harbott (frickler)","email":"frickler@offenerstapel.de","username":"jrosenboom"},"change_message_id":"42c9bf21e62b96fc3397700c77b66dd711427b5d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"d1868e89_d0b12730","updated":"2025-04-04 05:03:28.000000000","message":"detailed responses inline, to summarize: I\u0027d still hold up my -1 if this was rebased, since I don\u0027t think a technical workaround to a pure organizational problem is the correct solution","commit_id":"9cd78f9546e7e3ce1b0217d9a2be9808fdf480b8"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2162373e0558d72ff9c1910213620c4ff4c4bd34","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"7164e821_a15dc763","updated":"2025-04-04 11:18:49.000000000","message":"im not + or - one on this mainly because i dont know what the best path forward is\n\nits an annoying pain point for both reviewers and contibutors today and its not really workign well for us but i also get wehre the release team are coming form.","commit_id":"9cd78f9546e7e3ce1b0217d9a2be9808fdf480b8"},{"author":{"_account_id":12898,"name":"Tony Breeds","email":"tony@bakeyournoodle.com","username":"tonyb"},"change_message_id":"6d37a34b1972d6721ca15aa98481c08f597bd242","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"3d8d62f6_6238e622","in_reply_to":"04029aca_58dc6c63","updated":"2025-04-05 06:29:40.000000000","message":"1) Yup just land the denylist.txt part and the proposal-bot will handle the removal from u-c.   Given that u-c already has 3.4.0[1] this shouldn\u0027t cause you any pain.\n\n2) Got it \"One-Time-Use\"\n\nI checked the release tooling and removing os-traits from u-c shouldn\u0027t cause any problems WRT to proposing updates.\n\nAs to the future of this patch, given the role/nature of os-traits I\u0027m okay with adding the exception.\n\n[1] https://opendev.org/openstack/requirements/src/branch/master/upper-constraints.txt#L362","commit_id":"9cd78f9546e7e3ce1b0217d9a2be9808fdf480b8"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"85a5e5e785d5d94a3c0203c1cceac9561ca4c369","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"fcd0ab67_7cb8d444","in_reply_to":"31620c33_c026dce6","updated":"2025-04-09 14:48:00.000000000","message":"Sorry, I missed this reply somehow. Thanks for the prescription, but I think we just agreed in the Nova PTG session to deprecate and remove os-traits and os-resource-classes entirely to sidestep this problem and the release requirements in general. That discussion might have been different if I had seen this reply, but I was going on the assumption that this had stalled out.\n\nSo I\u0027ll abandon this on the assumption that we\u0027ll just delete these libraries entirely and if it doesn\u0027t pan out, I\u0027ll restore it and do what you say here.","commit_id":"9cd78f9546e7e3ce1b0217d9a2be9808fdf480b8"},{"author":{"_account_id":13252,"name":"Dr. Jens Harbott","display_name":"Jens Harbott (frickler)","email":"frickler@offenerstapel.de","username":"jrosenboom"},"change_message_id":"42c9bf21e62b96fc3397700c77b66dd711427b5d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"d9613227_41b7b35a","in_reply_to":"4e67a17f_7084df8a","updated":"2025-04-04 05:03:28.000000000","message":"\u003e OTU is the feature in nova I\u0027m working on that required me to modify os-traits, release os-traits, bump u-c, then bump our requirement... all to get a single string constant available to me :)\n\nso the only step that you could avoid with this patch is the \"bump u-c\" step, which is technically the easiest one, since the patch is automatically created after a release. IMO the real issue you are trying to work around is the lack of enough active contributors for the requirements project. if we had a bot that not only proposes the change, but also automatically merges it when the CI passes, would you still be wanting this patch? or are you rather unhappy with the traits-as-a-library concept in general? and how about just joining the requirements team instead?","commit_id":"9cd78f9546e7e3ce1b0217d9a2be9808fdf480b8"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"0d97a6d04883f07576d302d87c6f778eb9393bdd","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"4e67a17f_7084df8a","in_reply_to":"bdc247d5_635efde5","updated":"2025-04-03 13:29:02.000000000","message":"\u003e A couple of things.\n\u003e \n\u003e 1) To avoid merge conflicts I suggest only modfying denylist.txt.  Yes this will leave os-traits in upper-constraints.txt but only until the bot change to synchronise things lands.  Famous last words but I don\u0027t think that\u0027ll be a big problem.\n\nDoes that mean we add to denylist, land, then land another fix to remove? Or will the bot propose the removal?\n\n\u003e 2) What is \u0027otu-traits\u0027?  does the \u0027otu\u0027 mean something I\u0027m missing?\n\nOTU is the feature in nova I\u0027m working on that required me to modify os-traits, release os-traits, bump u-c, then bump our requirement... all to get a single string constant available to me :)","commit_id":"9cd78f9546e7e3ce1b0217d9a2be9808fdf480b8"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d2a3a3f6d1044252e69f71deb4d20ea1da0ce24d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"04029aca_58dc6c63","in_reply_to":"d9613227_41b7b35a","updated":"2025-04-04 13:53:52.000000000","message":"\u003e IMO the real issue you are trying to work around is the lack of enough active contributors for the requirements project.\n\nThat may be partially true, but it\u0027s still a step in a sort of insane process that doesn\u0027t need to exist (for this package). To flip it around, since an upper constraint on os-traits literally doesn\u0027t make sense, why would be want to keep burdening the limited resources of the requirements team with something that very literally does not need a constraint\n\n\u003e if we had a bot that not only proposes the change, but also automatically merges it when the CI passes, would you still be wanting this patch?\n\nThat would be better obviously, but it\u0027s still a step that does not need to be in the process. It introduces more latency (even if the bot is fast) and depends on the bot being written to do this, maintained, etc. We literally already have a denylist for things like this.\n\n\u003e or are you rather unhappy with the traits-as-a-library concept in general?\n\nI surely am, but at the moment that\u0027s what we\u0027ve got and making it as painless as possible seems like a reasonable goal to me.","commit_id":"9cd78f9546e7e3ce1b0217d9a2be9808fdf480b8"}],"denylist.txt":[{"author":{"_account_id":13252,"name":"Dr. Jens Harbott","display_name":"Jens Harbott (frickler)","email":"frickler@offenerstapel.de","username":"jrosenboom"},"change_message_id":"0fc9881c1dec942a03826f3fbbd1159e46a83165","unresolved":true,"context_lines":[{"line_number":37,"context_line":""},{"line_number":38,"context_line":"# The os-traits library is just a bunch of string constant values, and"},{"line_number":39,"context_line":"# projects can specify the versions they care about in their own requirements."},{"line_number":40,"context_line":"os-traits"},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"# Projects are free to specify their own version of ansible and molecule"},{"line_number":43,"context_line":"ansible"}],"source_content_type":"text/plain","patch_set":2,"id":"c1ac95f7_e3ba2bb6","line":40,"updated":"2025-04-03 03:23:45.000000000","message":"So this is a real library that will become part of the delivered product, right? Then a distro will need to package one specific version of it for a release and cannot have different versions per project. Having a pinned version in u-c ensures that this is feasible and I don\u0027t think we should easily give up on that.\n\nBut maybe my understanding is incomplete, why would a bunch of string constants be different in this regard from a bunch of funtions?","commit_id":"9cd78f9546e7e3ce1b0217d9a2be9808fdf480b8"},{"author":{"_account_id":13252,"name":"Dr. Jens Harbott","display_name":"Jens Harbott (frickler)","email":"frickler@offenerstapel.de","username":"jrosenboom"},"change_message_id":"42c9bf21e62b96fc3397700c77b66dd711427b5d","unresolved":true,"context_lines":[{"line_number":37,"context_line":""},{"line_number":38,"context_line":"# The os-traits library is just a bunch of string constant values, and"},{"line_number":39,"context_line":"# projects can specify the versions they care about in their own requirements."},{"line_number":40,"context_line":"os-traits"},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"# Projects are free to specify their own version of ansible and molecule"},{"line_number":43,"context_line":"ansible"}],"source_content_type":"text/plain","patch_set":2,"id":"a1bc9a8f_67b62127","line":40,"in_reply_to":"2475df4c_d1aa9871","updated":"2025-04-04 05:03:28.000000000","message":"\u003e jsut to double down on this. the contract we have with os-traits is we never remove traits once added.\n\u003e \n\u003e we are selective in adding new traits as a result which often cuases a lot of pain couming up to FF was we can have several change stuck behind doign a release to add the traits but if we are unsure we can deliver the full freature that can cause teh review to stall out in a chicken and egg situration.\n\u003e \n\u003e \n\u003e we do have min version that we pinn placment too each release for os-traits and os-resouce clases.\n\u003e \n\u003e while there is a lib compont to both they are really just data packages\n\u003e wehre the data is really jsut a set of constants expressed as strings.\n\u003e \n\u003e i think decoupleing os-trait and os-resoucs classes could be useful in general.\n\u003e \n\u003e while we do not backprot traits, getting them form a new release in a stable branch should nto break things.\n\u003e \n\u003e on master pinning to a specific version of os-trait adds littel value. on stable pinning to a major release could to prevent any possibel regressiosn with the very small set of funcitons that os-trait provide.\n\u003e \n\u003e is there a compmise we can maek so we only need to have a requirement bump on a major release (when there are breaking changes) ?\n\nas I wrote above, the \"need to have a requirement bump\" IMHO is a small step in comparison to \"need to have a new release made\", so I would argue that dropping it is an unneccessary optimization.\n\nI also gather from your description that os-traits is indeed snowflakey, but it is still far away from other stuff in the denylist list like linters that do not make it into the finished product at all","commit_id":"9cd78f9546e7e3ce1b0217d9a2be9808fdf480b8"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"dfb0a5b690fe03cc6e6ec352752301c62f554455","unresolved":true,"context_lines":[{"line_number":37,"context_line":""},{"line_number":38,"context_line":"# The os-traits library is just a bunch of string constant values, and"},{"line_number":39,"context_line":"# projects can specify the versions they care about in their own requirements."},{"line_number":40,"context_line":"os-traits"},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"# Projects are free to specify their own version of ansible and molecule"},{"line_number":43,"context_line":"ansible"}],"source_content_type":"text/plain","patch_set":2,"id":"7f503c98_ab2c3bf6","line":40,"in_reply_to":"3e5fbbc5_c85665c6","updated":"2025-04-04 19:59:22.000000000","message":"\u003e \u003e im not actully sure what the best path forward is but the utility of having os-trait and os-resouce classes as seperate deliverable is questionable so it might be the case that we would be better off absoring them back into nova. its a conversation i think we shoudl have next week with the wirider nova/placment team.\n\u003e \n\u003e I\u0027m very much in favor of absorbing them back into something (seems like placement would be better). I think that making a generic tool that can generate a manifest of the resource classes and traits that we sync/update in nova any time we add a new one to placement would be fine. They\u0027re just string constants and really serve almost no purpose at runtime other than that.\n\nI was not part of the discussion so I might miss something but I also do not find any strong reason why os-traits (even os-resource-classes) need to be a separate lib. Because that gives less benefits but more overhead of extra releases, upper-contraints, and testing/packaging work. merging them in palcement is best close place to do.\n\n\u003e I also don\u0027t want to shoot for the above ideal (which is not a trivial amount of work), have it lose steam and also not land this denylist change. Perhaps the intent to eliminate this dance entirely is enough for the requirements team to allow this to proceed in the meantime to reduce some of the friction?\n\n\nI agree. I am not sure we should treat os-traits lib (having a set of constants only) the same as other and apply the mandate of u-c. Seeing a few neutron lib and tempest convience me to not have mandatory u-c for this lib which make process easy. To make the development process as easy as we can, the right path here can be to allow it in deny list now and later nova team can decide about merging it in placement/nova.","commit_id":"9cd78f9546e7e3ce1b0217d9a2be9808fdf480b8"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d2a3a3f6d1044252e69f71deb4d20ea1da0ce24d","unresolved":true,"context_lines":[{"line_number":37,"context_line":""},{"line_number":38,"context_line":"# The os-traits library is just a bunch of string constant values, and"},{"line_number":39,"context_line":"# projects can specify the versions they care about in their own requirements."},{"line_number":40,"context_line":"os-traits"},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"# Projects are free to specify their own version of ansible and molecule"},{"line_number":43,"context_line":"ansible"}],"source_content_type":"text/plain","patch_set":2,"id":"3e5fbbc5_c85665c6","line":40,"in_reply_to":"471ac966_2f9e8763","updated":"2025-04-04 13:53:52.000000000","message":"\u003e we could keep doing the release dance but to be clear, i will be proposing another os-traits release fo new traits we added since the last one dan did later today.\n\u003e which means another patch to the requirement repo too.\n\nRight, this points out how silly this is. We did it yesterday and we\u0027re going to do it today. For something that does not need an upper constraint.\n\n\u003e im not actully sure what the best path forward is but the utility of having os-trait and os-resouce classes as seperate deliverable is questionable so it might be the case that we would be better off absoring them back into nova. its a conversation i think we shoudl have next week with the wirider nova/placment team.\n\nI\u0027m very much in favor of absorbing them back into something (seems like placement would be better). I think that making a generic tool that can generate a manifest of the resource classes and traits that we sync/update in nova any time we add a new one to placement would be fine. They\u0027re just string constants and really serve almost no purpose at runtime other than that.\n\nI also don\u0027t want to shoot for the above ideal (which is not a trivial amount of work), have it lose steam and also not land this denylist change. Perhaps the intent to eliminate this dance entirely is enough for the requirements team to allow this to proceed in the meantime to reduce some of the friction?","commit_id":"9cd78f9546e7e3ce1b0217d9a2be9808fdf480b8"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2162373e0558d72ff9c1910213620c4ff4c4bd34","unresolved":true,"context_lines":[{"line_number":37,"context_line":""},{"line_number":38,"context_line":"# The os-traits library is just a bunch of string constant values, and"},{"line_number":39,"context_line":"# projects can specify the versions they care about in their own requirements."},{"line_number":40,"context_line":"os-traits"},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"# Projects are free to specify their own version of ansible and molecule"},{"line_number":43,"context_line":"ansible"}],"source_content_type":"text/plain","patch_set":2,"id":"471ac966_2f9e8763","line":40,"in_reply_to":"a1bc9a8f_67b62127","updated":"2025-04-04 11:18:49.000000000","message":"To me os-traits is like tempest\n\nthere is a poirnt in its lifecycle when it makes sense to pin.\nfor tempest that when branches are movign to unmaintained.\nfor os-traits that wehn we branch the major version\n\nat all ohter time it makes more sense for master to track master\njust like we use master placmenet with maser nova.\n\nhaving os-trait as a seperate lib was only done becuase we want to have a way to import them without having to import all of nova or all of placement.\n\nwhat might be better is to change how we use it going forward.\n\n\nwe could swap nova to use os-traits form souce just by addign it to libs form git and modify our tox jobs to install it in a similar way.\n\nwe could fold os-traits and os-resouce classes into the placement or nova git repo as additional libs that we release form them but allow use to use them directly in treee prior to a release. so we would do 1 os-traits release a cycle (technialy we would probely do one every time we do a nova release btu like m1, FF, RC1) and not need to do any releases to land a feature in nova or placement depending on where we put it.\n\nwe could keep doing the release dance but to be clear, i will be proposing another os-traits release fo new traits we added since the last one dan did later today.\nwhich means another patch to the requirement repo too.\n\nim not actully sure what the best path forward is but the utility of having os-trait and os-resouce classes as seperate deliverable is questionable so it might be the case that we would be better off absoring them back into nova. its a conversation i think we shoudl have next week with the wirider nova/placment team.","commit_id":"9cd78f9546e7e3ce1b0217d9a2be9808fdf480b8"},{"author":{"_account_id":12898,"name":"Tony Breeds","email":"tony@bakeyournoodle.com","username":"tonyb"},"change_message_id":"28feb35a59c24cee446d4b02a226c68d772cd03b","unresolved":true,"context_lines":[{"line_number":37,"context_line":""},{"line_number":38,"context_line":"# The os-traits library is just a bunch of string constant values, and"},{"line_number":39,"context_line":"# projects can specify the versions they care about in their own requirements."},{"line_number":40,"context_line":"os-traits"},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"# Projects are free to specify their own version of ansible and molecule"},{"line_number":43,"context_line":"ansible"}],"source_content_type":"text/plain","patch_set":2,"id":"de37bf23_8858e201","line":40,"in_reply_to":"c1ac95f7_e3ba2bb6","updated":"2025-04-03 06:20:10.000000000","message":"You\u0027re correct.  The assertion is that as it\u0027s a library that is \u0027additive\u0027 only *and* only contains constant strings (no code/functaional changes/bugs) the likelihood of it causing a regression is low (but I guess non-zero).\n\nA project may specify a minimum version, but there is no reason for it to add a maximum version, so from a distro POV just pick the \"highest minimum\"?\n\nI\u0027m fine with this exception, but I don\u0027t really see a \"great advantage\" to it.\n\n#shrug","commit_id":"9cd78f9546e7e3ce1b0217d9a2be9808fdf480b8"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"0d97a6d04883f07576d302d87c6f778eb9393bdd","unresolved":true,"context_lines":[{"line_number":37,"context_line":""},{"line_number":38,"context_line":"# The os-traits library is just a bunch of string constant values, and"},{"line_number":39,"context_line":"# projects can specify the versions they care about in their own requirements."},{"line_number":40,"context_line":"os-traits"},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"# Projects are free to specify their own version of ansible and molecule"},{"line_number":43,"context_line":"ansible"}],"source_content_type":"text/plain","patch_set":2,"id":"e205e515_f078c32a","line":40,"in_reply_to":"de37bf23_8858e201","updated":"2025-04-03 13:29:02.000000000","message":"It\u0027s additive only so the only thing that matters to a project is the minimum version. My other suggestion besides this is to just always pin to \u003c4. Theoretically we\u0027d need a major version if we ever removed anything, and at least \u003c4 would let us avoid the dance until that point. Not sure if the bot allows that though.\n\nI see it as a \"great advantage\" to cut out the u-c bump from the already-ridiculous set of steps we have to do every time we want to add a new string constant. It was pretty quick this time, but it\u0027s not always that way.","commit_id":"9cd78f9546e7e3ce1b0217d9a2be9808fdf480b8"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"bb68a2d6c08ce2746d0e5e47cfe3f668dea0b471","unresolved":true,"context_lines":[{"line_number":37,"context_line":""},{"line_number":38,"context_line":"# The os-traits library is just a bunch of string constant values, and"},{"line_number":39,"context_line":"# projects can specify the versions they care about in their own requirements."},{"line_number":40,"context_line":"os-traits"},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"# Projects are free to specify their own version of ansible and molecule"},{"line_number":43,"context_line":"ansible"}],"source_content_type":"text/plain","patch_set":2,"id":"2475df4c_d1aa9871","line":40,"in_reply_to":"e205e515_f078c32a","updated":"2025-04-03 14:11:45.000000000","message":"jsut to double down on this. the contract we have with os-traits is we never remove traits once added.\n\nwe are selective in adding new traits as a result which often cuases a lot of pain couming up to FF was we can have several change stuck behind doign a release to add the traits but if we are unsure we can deliver the full freature that can cause teh review to stall out in a chicken and egg situration.\n\n\nwe do have min version that we pinn placment too each release for os-traits and os-resouce clases.\n\nwhile there is a lib compont to both they are really just data packages\nwehre the data is really jsut a set of constants expressed as strings.\n\ni think decoupleing os-trait and os-resoucs classes could be useful in general.\n\nwhile we do not backprot traits, getting them form a new release in a stable branch should nto break things.\n\non master pinning to a specific version of os-trait adds littel value. on stable pinning to a major release could to prevent any possibel regressiosn with the very small set of funcitons that os-trait provide.\n\nis there a compmise we can maek so we only need to have a requirement bump on a major release (when there are breaking changes) ?","commit_id":"9cd78f9546e7e3ce1b0217d9a2be9808fdf480b8"}]}