Skip to content

Commit

Permalink
Initial Kodi v18 version.
Browse files Browse the repository at this point in the history
  • Loading branch information
@ksooo
ksooo committed Dec 5, 2016
1 parent 4b06d83 commit 4d17aaf
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion pvr.vdr.vnsi/addon.xml.in
View file
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<addon
id="pvr.vdr.vnsi"
version="2.6.9"
version="3.0.0"

This comment has been minimized.

Sign in to view

Copy link
@FernetMenta

FernetMenta Dec 15, 2016

Contributor

what is that? does not comply with my version schema :(

This comment has been minimized.

Sign in to view

Copy link
@ksooo

ksooo Dec 15, 2016

Author Member

Last time I bumped all major numbers for all pvr addons (did somebody say monkey work?) for initial Krypton version after branching you did not complain. I did not know that pvr.vdr.vnsi has it's "own" versioning scheme.

This comment has been minimized.

Sign in to view

Copy link
@FernetMenta

FernetMenta Dec 16, 2016

Contributor

It just feels wrong to bump major for this case. IMO minor is much more reasonable.

This comment has been minimized.

Sign in to view

Copy link
@ksooo

ksooo Dec 16, 2016

Author Member

The idea is: new Kodi major => new add-on major. We did that for Krypton as well and I think this is a good idea, I actually would like to use the same major for both Kodi and the add-ons. :-)

This comment has been minimized.

Sign in to view

Copy link
@FernetMenta

FernetMenta Dec 16, 2016

Contributor

finally this is a decision of the addon authors. it does not have any impact on how the addon is built or packaged.

This comment has been minimized.

Sign in to view

Copy link
@AlwinEsch

AlwinEsch Dec 16, 2016

Contributor

From my side is "new Kodi major => new add-on major" a not good way.

A add-on interface version need to stays independent from Kodi's Version. Currently has this dll on linux pvr.vdr.vnsi.so.18.0 but for me makes it more sense to use the API version (here <import addon="xbmc.pvr" version="5.2.1"/>) and to have pvr.vdr.vnsi.so.5.2.1.

If now comes a big code change makes it sense to increase the major, but without is it confused. After my head, is major version increase about a very big change.

As long now is no API change is it not needed to change a version and whether v17 or v18.

Changes about them come also soon in my rework.

This comment has been minimized.

Sign in to view

Copy link
@FernetMenta

FernetMenta Dec 16, 2016

Contributor

I think so too. In particular in the context of rero a major version bump of addons makes no sense for a new release of Kodi. There may not even be a single change regarding addons.

This comment has been minimized.

Sign in to view

Copy link
@ksooo

ksooo Dec 16, 2016

Author Member

A add-on interface version need to stays independent from Kodi's Version. Currently has this dll on linux pvr.vdr.vnsi.so.18.0 but for me makes it more sense to use the API version (here ) and to have pvr.vdr.vnsi.so.5.2.1.

Imo, we should not mix api version and addon version in this discussion. This are different things. There can be a lot of addon versions for one api version and you need to distinguish addon versions. Think of (OTA) addon updates which are always based on version number.

I agree that it makes sense to name shared libraries according to the api version, but again, this is not related to the addon version bump discussion.

This comment has been minimized.

Sign in to view

Copy link
@ksooo

ksooo Dec 16, 2016

Author Member

In particular in the context of rero a major version bump of addons makes no sense for a new release of Kodi. There may not even be a single change regarding addons.

Technically, yes. But from user's point of view it makes very clear which addon (version) is the correct one for "my" Kodi. I tried just to be user oriented, that's the whole point.

This comment has been minimized.

Sign in to view

Copy link
@ksooo

ksooo Dec 16, 2016 •
edited

Author Member

No drama, but i guess next time I will refrain from updating any other addon than the one I'm the maintainer for. Maybe this is best to keep my blood pressure down. ;-)

This comment has been minimized.

Sign in to view

Copy link
@FernetMenta

FernetMenta Dec 17, 2016

Contributor

This was my proposal from the beginning. Let's delete this silly pvr repo and give ownership to the addon maintainers.
name="VDR VNSI Client"
provider-name="FernetMenta, Team Kodi">
<requires>
Expand Down

8 comments on commit 4d17aaf

@AlwinEsch
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah sh.., sorry, part of another part with complete reworked system.
I can create a change if acceptable now.

@AlwinEsch
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ups, thought was changed from me, has used several values to check the version compare on Kodi.

@Jalle19
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@FernetMenta the reason it makes sense to bump the major version is so that there is less confusing regarding backported version bumps. Now you may end up with situations where 2.7.1 is for Krypton but 2.7.2 is for Jarvis etc.

@Jalle19
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Plus an addon for Kodi v18 most definitely won't work for Kodi v17, so a major version bump seems entirely appropriate to me.

@FernetMenta
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as already mentioned: my addon, my decision

@AlwinEsch
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With the "won't work" is not exactly true. The add-ons have a C Interface with function table and currently own C headers, as long this is not changed can be e.g. a screensaver from v12 also used on v17.

Due to the bigger changes on e.g. PVR, was it OK, but not the right. As long a add-on header is not changed is also not needed to change add-on version.

@ksooo
Copy link
Member Author

@ksooo ksooo commented on 4d17aaf Dec 18, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As long a add-on header is not changed is also not needed to change add-on version.

Again, don't mix API version and addon version, please. API is for technical changes, to ensure compatibility. Addon version is (also) for functional changes. If I add a new feature to an addon, without changing the Kodi addon API, I will ofc, not bump the API version, but I will bump the addon version (for instance to announce to users, "hey new addon version x.y.z supports PVR backend feature foo". Seems, we are not talking the same language?!

@AlwinEsch
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @ksooo you're right. Was for my so clear with a change on code that I not written it :)

Please sign in to comment.