2013-12-02, 12:43
Ehhhrrmm just a bit as a sidenode. I am maintainer of 2 addons (boblight, and unpausejumpback) - i didn't get any info if i need to change anything and have to do a new pull request. Is there anything i need to do or what?
2013-12-02, 12:51
(2013-12-02, 12:43)Memphiz Wrote: Ehhhrrmm just a bit as a sidenode. I am maintainer of 2 addons (boblight, and unpausejumpback) - i didn't get any info if i need to change anything and have to do a new pull request. Is there anything i need to do or what?
so you don't follow threads it seems
it was posted on:
- mailinglist
- google+
- xbmc.org blogpost
- Gotham python changes http://forum.xbmc.org/showthread.php?tid=173943
- http://wiki.xbmc.org/index.php?title=add...y_versions
- http://wiki.xbmc.org/index.php?title=XBM...ges#Addons
- http://wiki.xbmc.org/index.php?title=Got...ges#Addons
Was also asked here:
- http://forum.xbmc.org/showthread.php?tid=177480
so what more is to be expected to any one to notice?
however it seems you already had Python API 2.1.0 version so no you don't have to change anything (afaik).
and if boblight stopped working i would be the first one to complain about it
2013-12-02, 17:23
Haha - i should get mails from the mailing list i guess. *wonders* - sorry for the noise. But i of course expect a naked girl ringing on my door and telling me to bump my python - do i expect to much? ^^
2013-12-03, 10:01
2013-12-10, 21:55
(2013-12-03, 10:01)Kib Wrote:(2013-12-02, 17:23)Memphiz Wrote: But i of course expect a naked girl ringing on my door and telling me to bump my python - do i expect to much? ^^
Bump my python
*wink*wink*
Nice
there are some things that cant be unseen, you read it and get a picture that never ever goes away ... damn
2015-12-18, 09:39
(2013-11-29, 06:59)jmarshall Wrote: As anyone who has run Gotham alpha's since A9 knows, the xbmc.python bump caused a bit of a hassle. On the plus side, that hassle highlighted some bugs, on the minus the constant nagging isn't much fun...
If a change is required anyway due to things being broken, then fair enough, the minimum backward compatibility version needs bumping.
However, if things aren't broken, why force add-on authors to make changes they wouldn't otherwise need to do?
I propose that we revert the xbmc.python minimum versioning to 2.0, under the assumption that it is still backward compatible to 2.0. If it's still compatible, there's no reason to bump it.
Opinions most welcome - if there's a decent reason why it was bumped, then please elaborate what that is.
Cheers,
Jonathan
This clearly indicates that this mechanism needs some rework. Doing a versioning "under the assumption" and pretending things are compatible that actually are not is wrong. Either an API is compatible or not. I would rather drop this entirely than keeping the current state. This parameter is worth absolutely nothing if you can't rely on it.
2015-12-18, 13:05
If I understood correctly it's down to this:
I think the main problem in the PR was, that a global abi/api is pretty much useless here.
Why would we need value that can kill off all addons we have? It's really hard to find a usecase for that. It needs to be much more granular, even if that means you need to edit multiple flags in some cases.
I think the main problem in the PR was, that a global abi/api is pretty much useless here.
Why would we need value that can kill off all addons we have? It's really hard to find a usecase for that. It needs to be much more granular, even if that means you need to edit multiple flags in some cases.
2015-12-18, 14:34
I didn't follow the entire drama, but it looks to me that if an Android app from API 8 can still work on current API 23, we should be able to do the same, and they have no more granularity.
I.e. (as Razze proposed, iirc), deprecate interfaces but not remove them and insure backward compatibility.
What's preventing it in the specific RenderCapture case?
I.e. (as Razze proposed, iirc), deprecate interfaces but not remove them and insure backward compatibility.
What's preventing it in the specific RenderCapture case?
2015-12-18, 14:52
(2015-12-18, 14:34)Koying Wrote: I didn't follow the entire drama, but it looks to me that if an Android app from API 8 can still work on current API 23, we should be able to do the same, and they have no more granularity.
I.e. (as Razze proposed, iirc), deprecate interfaces but not remove them and insure backward compatibility.
What's preventing it in the specific RenderCapture case?
Some of our crappy interfaces do expose internals and rely on globals. RenderCapture broke because RenderManager is not global anymore. IMO it makes no sense to maintain backward compatibility to bad designed interfaces. In order to move forward we should leave that crap behind. No big deal if an interface changes and authors get informed half a year in advance. In this specific case the script can be adapted in minutes. Not worth bothering about this.
Bottom line is that interface changes happened in the past and will happen in the future. The question is how to deal with those with regard on "backwards-compatibility". Currently this parameter is treated as "don't touch, or this will be the end of the world". If this is the case, I suggest to get rid of it.
2015-12-18, 15:14
For me, bottom-line is: Do we do Kodi professionally or leisurely?
If professionally , we have to assume past mistakes and bite the buttlet by keeping backward-compatibility in some way, even if hackish/ugly.
If leisurely, we can say "let's make it proper, the hell with history".
That's more a philisophical question, really
If professionally , we have to assume past mistakes and bite the buttlet by keeping backward-compatibility in some way, even if hackish/ugly.
If leisurely, we can say "let's make it proper, the hell with history".
That's more a philisophical question, really
2015-12-18, 15:58
I can't agree with this pov. Maintaining crap by doing almost nothing, protecting an outdated code base with only half working features, rejecting new ideas, ... is not professional. This happened a lot in the past. Transforming an architecture inevitable results in breaking backwards compatibility every now and then.
In the case of RenderCapture I would rather fix the two or three python scripts myself than allowing the old crap to get back into the code.
If somebody manages it to implement backwards compatibility without doing a single line of hack to core, be my guest. I certainly won't waste my time on this.
In the case of RenderCapture I would rather fix the two or three python scripts myself than allowing the old crap to get back into the code.
If somebody manages it to implement backwards compatibility without doing a single line of hack to core, be my guest. I certainly won't waste my time on this.
2015-12-18, 16:31
You must have been far more lucky in your professional life than I, then
2015-12-18, 16:58
Not long ago I upgraded iOS on my iPAD and a Texas Instruments app stopped working. It took maybe 2 weeks until TI provided a fix via the app store. I don't see any unprofessionalism in this case.
Today I received an email from our IT department with recommendation not to upgrade to new iOS 9.2. Already done yesterday
According to the email I would get some update issues with our internal apps. No big deal, christmas holidays are near. I can live with that, too.
I work in the field and one day some time ago an admin at a client site insulted me (I did not write this sw), way beyond any professionalism. What I want to say is that even in professional life clients are not always happy. I think we are not doing not a bad job, even if we break some parts of the api every now and than.
Today I received an email from our IT department with recommendation not to upgrade to new iOS 9.2. Already done yesterday
According to the email I would get some update issues with our internal apps. No big deal, christmas holidays are near. I can live with that, too.Quote:You must have been far more lucky in your professional life than I, then
I work in the field and one day some time ago an admin at a client site insulted me (I did not write this sw), way beyond any professionalism. What I want to say is that even in professional life clients are not always happy. I think we are not doing not a bad job, even if we break some parts of the api every now and than.
