On 03/21/2013 02:25 PM, Don Zickus wrote:
The problem is I have two python bugzilla environments: 0.7.0 and 0.8.0. Some windows have the PYTHONPATH set up and get 0.8.0 other do not and get 0.7.0. The flags attribute is accessed differently in different versions. Very annoying.
Now the rhbz_back_compat can fix that. However, I can't use that variable on 0.7.0 as it doesn't exist. Boooo!
So to help ease transition to the new reality, set rhbz_back_compat to True for now. Then once 0.8.0 is out, folks can slowly set 'rhbz_back_compat' to False as their scripts are updated.
Then with 0.9.0 comes along, the default can be set to False.
I don't disagree with the change for rhbz_back_compat, I just need (and others too) a slightly smoother migration path.
Thanks for the patch Don, however I'd like to avoid this if possible.
python-bugzilla-0.8.0 has been available in updates-testing for F17+ and epel5/6 for a month now. I realize updates-testing isn't the most obvious thing to some users, but that should be all the upgrade path we need. Is that sufficient or am I missing something?
0.8.0 changed a lot of things, so it's probably going to break things for some people. Turning this option on by default is going to postpone some of the complaints until a future date. But what I really want is to get all the complaints/breakage/bugreports condensed into the narrowest time window possible to ease the maintenance burden. So turning this option back on is an absolute last resort in my mind.
Also, you can always do
rhbz = RHBugzilla(url=...,...) rhbz.rhbz_back_compat = True
on both 0.7.0 and 0.8.0 so at least code will be compatible, although of course that option will do nothing on 0.7.0.
Thanks, Cole