Permalink
Browse files

Merge pull request #12 from hudokkow/bump

Bump add-on (libplatform dependency)
  • Loading branch information...
hudokkow committed Jun 30, 2015
2 parents 9a569ec + 7014f28 commit 92cea88906bad3e1e9072ec7f2bd6ca0fbaedf3d
Showing with 1 addition and 1 deletion.
  1. +1 −1 pvr.demo/addon.xml
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<addon
id="pvr.demo"
version="1.10.5"
version="1.10.6"
name="PVR Demo Client"
provider-name="Pulse-Eight Ltd.">
<requires>

19 comments on commit 92cea88

@MilhouseVH

This comment has been minimized.

MilhouseVH replied Jul 3, 2015

This latest bump seems to be missing from master (on all pvr repos) - shouldn't updates be applied to master first, then Isengard?

@hudokkow

This comment has been minimized.

Contributor

hudokkow replied Jul 3, 2015

@ksooo will bump all addons on master after xbmc/xbmc#7079 is in

@MilhouseVH

This comment has been minimized.

MilhouseVH replied Jul 3, 2015

OK thanks, although in general it would be good if Isengard "followed" master otherwise users on "master" builds may suddenly find themselves downloading Isengard PVR addons which is what happened to OpenELEC bleeding edge testers last night - their latest Milhouse test build shipped with master pvr.demo 1.10.5 last night, while the OpenELEC online repo bumped to Isengard pvr.demo 1.10.6 (and the same for all other pvr.* addons). Now I need these master testers to remove the downloaded Isengard addons so they revert to using the shipped "master" addons... In theory this should never happen.

@MartijnKaijser

This comment has been minimized.

Member

MartijnKaijser replied Jul 3, 2015

and tell me exactly why that is a problem? Repo works in the way that highest addon version always prevails. Now master has higher version number the bumped ones from OE repo just became useless as the ones from master are preferred again.
Any way. They run bleeding edge so shit can break. That's something they need to accept.

@MilhouseVH

This comment has been minimized.

MilhouseVH replied Jul 3, 2015

Yes, eventually it will right itself, my point is it shouldn't have happened and this is something we are responsible for - pushing new stuff to a branch and then following up a day or so later on master seems arse about face.

@MartijnKaijser

This comment has been minimized.

Member

MartijnKaijser replied Jul 3, 2015

i really do not see your point. Doing absolutely pointless bumps is a waste of time.

@MilhouseVH

This comment has been minimized.

MilhouseVH replied Jul 3, 2015

So you think it's correct to push updates to a branch before pushing updates to master? Seriously?

As for why this happened, I build master. Period. If master lags behind some other branch, shit happens. This is entirely avoidable, by keeping master up to date ahead of all branches.

Of course I could just stop building PVR addons, which is something I'm seriously considering because they're a pain in the arse - what users will do to test new PVR addon commits I'll leave up to you, particularly as it will only cause more crashes when incompatible Isengard addons are installed against Kodi 16.

@opdenkamp

This comment has been minimized.

Contributor

opdenkamp replied Jul 3, 2015

particularly as it will only cause more crashes when incompatible Isengard addons are installed against Kodi 16.

no, that's why we have api versions.

as for pushing to the branch that's going to be released first: that's one of the recommended branch structures. branch off release, fix release, merge back in. not that we do that very well, but it's not wrong either.

@opdenkamp

This comment has been minimized.

Contributor

opdenkamp replied Jul 3, 2015

and each kodi version should have it's own add-on repos, which I believe is what openelec has been doing for quite some time.

@MilhouseVH

This comment has been minimized.

MilhouseVH replied Jul 3, 2015

Yes, and this is partly my problem but I'm not using OpenELEC repos to host my own PVR addon builds - I've been including the PVR addons in the build, so there's been no need to download the addons from any repo as the build always contained the very latest (master) version of the PVR addons.

Once the Isengard PVR branches went ahead of master, and the OpenELEC repo contained the newer Isengard versions of the PVR addons, Kodi proceeded to download the "newer" (Isengard) addons in preference to my already installed "master" versions.

It's perhaps not the recommended approach, but has been fine until master for no particular reason lagged Isengard.

I think I'll most likely just stop building PVR addons if this is likely to happen again, and let it become someone else's problem.

@opdenkamp

This comment has been minimized.

Contributor

opdenkamp replied Jul 3, 2015

that's your own choice, but all this work to turn these into proper add-ons hasn't been done just because people had too much time on their hands. if you treat them like add-ons, put them in a repos per kodi version and build them separately, then all you need to do really is point to the correct branch and build them.

including it in the image is indeed no longer the recommended approach. if openelec has newer versions of the add-ons in the repos, and your build points to that same repos (so is the same version of kodi), then what's the problem with these add-ons being upgraded? that's the whole point of having add-ons and have them in a repos.

@MilhouseVH

This comment has been minimized.

MilhouseVH replied Jul 3, 2015

if openelec has newer versions of the add-ons in the repos, and your build points to that same repos (so is the same version of kodi), then what's the problem with these add-ons being upgraded? that's the whole point of having add-ons and have them in a repos.

That's just it, they don't normally have newer versions - very rarely has OpenELEC carried the same PVR version as master, as master always had more recent commits. On this one occasion, however, they did manage to leap frog master...

Whatever, I'll drop PVR addons in the next build after tonight and people can download Isengard addons from the OE repo while testing with Kodi 16. If they crash, not my problem. If they want up to date PVR addons they'll need to source them from elsewhere, or build themselves.

@opdenkamp

This comment has been minimized.

Contributor

opdenkamp replied Jul 4, 2015

as I've said already, each kodi version should point to it's own repos for binary add-ons, then people can always download the latest (compatible!) version.

kodi checks the api against which the add-on was built, and will not run the add-on if the api is incompatible.

I don't see the problem

@MilhouseVH

This comment has been minimized.

MilhouseVH replied Jul 4, 2015

Since I'm only providing these builds for test purposes and don't have the full infra of OpenELEC, nor do I want to maintain that, I'll just stop providing the very latest PVR add-ons in my builds as I can no longer predict which version will be installed (or used) by the user.

Instead users can test with whatever version of PVR addon they find in their repos or - more likely - just stop testing.

@Jalle19

This comment has been minimized.

Contributor

Jalle19 replied Jul 4, 2015

I guess part of all this confusion is my fault since I created Isengard branches for all PVR addons a bit too early. Come next release it's probably best to delay that as long as possible.

@opdenkamp

This comment has been minimized.

Contributor

opdenkamp replied Jul 4, 2015

not really, I think it should be created at the same time as we create the release branch in core. we've now got an api change in master that breaks compat with the current release, so we need a release and a dev version of the add-ons.

@barberio

This comment has been minimized.

barberio replied Jul 4, 2015

Why are two different and binary incomparable API versions of the PVR addons presenting the same minior version number in the first place?

The J**** version of pvr.demo should then be at version number 1.11.x not 1.10.x, and similar minor version number bumps for others, which would solve this issue.

@MilhouseVH

This comment has been minimized.

MilhouseVH replied Jul 4, 2015

They're not, as master is once again ahead of the Isengard branch and master is using the new API. The problem now is that the only version of the add-ons available for download are using the old API.

@barberio

This comment has been minimized.

barberio replied Jul 4, 2015

But my understanding is that release-branch and master-branch binary addons are not intended to be binary compatible, so as soon as Isengard became the production branch, master should have had a minor increment to it's version number. Precisely to avoid potential intermingling of patch incremented Isengard branch and Master addons. This is what Major.Minor.Patch version numbers are for.

Please sign in to comment.