search

pupnp / pupnp

libupnp: Build UPnP-compliant control points, devices, and bridges on several operating systems.
https://pupnp.github.io/pupnp
BSD 3-Clause "New" or "Revised" License
352 stars 117 forks source link

1.8/2.0 Release #15

Closed whyman closed 7 years ago

whyman commented 7 years ago

Hi,

Please consider tagging a 1.8 series release. At the moment there isn't a release with the newer nicer API.

I've ported my fork of MediaTomb over to the master branch (and it works great!) and I would like to do a release of my code, but it feels wrong to make people install a git snapshot as a dependency.

I am willing to do whatever is needed myself to make this happen if that helps - just let me know what is needed. Though from my view it would just be a git tag and tarball. I am happy to provide maintenance on the branch also if needed, but you seem more than capable yourself.

Previously you mentioned that it required more testing - but after spending some time with it I am happy it is good to go.

Thanks!

ffontaine commented 7 years ago

Hi,

I would be more than happy to make a tag on the first 1.8.0 version. Marcello made a lot of work on this version.

My only concern is that the external API of the 1.8.x serie is not compatible with the 1.6.x serie. So, maintainers of the pupnp in the different buildsystems should not upgrade their version of pupnp as this will break most (all?) existing applications that depend on pupnp (igd2-for-linux, vlc, ushare, mediastreamer, mpd, ...).

So, maintainers should probably provide a dedicated pupnp-1.8 package like python3 / python2. However, if we do not change anything in the build system files, we'll not be able to install applications that depends on pupnp and pupnp-1.8 on the same machine, because both packages will share the same include path (xxx/include/upnp) and the same library names (libupnp, libthreadutil, libixml). So, I would suggest to rename 1.8.x to 2.x.x and to change the include path and library names to xxx/include/upnp2, libupnp2*, libupnp2.pc, ... I would like more feedback on this proposal (for example from @grahamc or @mrjimenez).

Best Regards,

Fabrice

whyman commented 7 years ago

So, I would suggest to rename 1.8.x to 2.x.x and to change the include path and library names to xxx/include/upnp2, libupnp2*, libupnp2.pc

Great idea, co-installable would be the best way to not break existing 1.6 users, then developers can move to the new API when they like.

grahamc commented 7 years ago

Fabrice Fontaine notifications@github.com writes:

So, I would suggest to rename 1.8.x to 2.x.x and to change the include path and library names to xxx/include/upnp2, libupnp2*, libupnp2.pc, ... I would like more feedback on this proposal (for example from @grahamc or @mrjimenez).

I'm actually not a great person to ask about this, I'm a packager for NixOS and libraries get well isolated under NixOS. Example:

/nix/store/1q73xw8l66ddzn2jvjfwdh2iz143rqiy-libupnp-1.6.20

$ ldd /bin/sh
linux-vdso.so.1 (0x00007ffd083dc000)
libreadline.so.6 => /nix/store/3yc5gzrrl0mrg79xw3ijchw2bj8d9mf6-readline-6.3p08/lib/libreadline.so.6 (0x00007fa2eb16d000)
libhistory.so.6 => /nix/store/3yc5gzrrl0mrg79xw3ijchw2bj8d9mf6-readline-6.3p08/lib/libhistory.so.6 (0x00007fa2eaf63000)
libncursesw.so.6 => /nix/store/gz5ph3m624zivi687zvy82izi2z39aik-ncurses-6.0/lib/libncursesw.so.6 (0x00007fa2eacf8000)
libdl.so.2 => /nix/store/jm1n87rp8vr90j9ahcrfzr57nc2r8vgf-glibc-2.24/lib/libdl.so.2 (0x00007fa2eaaf4000)
libc.so.6 => /nix/store/jm1n87rp8vr90j9ahcrfzr57nc2r8vgf-glibc-2.24/lib/libc.so.6 (0x00007fa2ea756000)
/nix/store/jm1n87rp8vr90j9ahcrfzr57nc2r8vgf-glibc-2.24/lib/ld-linux-x86-64.so.2 (0x00007fa2eb3b6000)

(However: I very seriously appreciate your considerations, and tagging me!)

ffontaine commented 7 years ago

Thanks for your answers. The only concern I have on my own proposal is that the UPnP Forum (now a part of OCF: https://openconnectivity.org) released in February 2015 the UPnP Device Architecture 2.0 (http://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v2.0.pdf). I fear that using upnp2 inside our package or library names could give the misleading impression that pupnp2 is compliant with this new UDA which is not the case. For example, SSDP messages do not include the new required headers such as BOOTID.UPNP.ORG or CONFIGID.UPNP.ORG.

whyman commented 7 years ago

Yes I agree that perhaps that number could be confusing.

Versioning per branch does make sense, so perhaps we go with xxx/include/upnp-1.8, libupnp-1.8*, libupnp-1.8.pc? This seems to be the scheme most versioned libraries are using on my system at least.

ffontaine commented 7 years ago

I'm ok with your suggestion. I prepared a patch with this change. If Marcelo is ok, I will commit it to the master branch. Then, you could test on your side that everything is ok with your version of mediatomb. Then, we could make the release.

ffontaine commented 7 years ago

I created the PR #16 so we could test and update the PR and keep the main repo's history as clean as possible.

mrjimenez commented 7 years ago

Lets do it.

Fabrice, thank you very much for the patch!

Regards, Marcelo.

whyman commented 7 years ago

Thanks guys, this looks awesome!

Ive managed to install 1.8 next to 1.6 on my system! 👍

I will try MediaTomb later today.

whyman commented 7 years ago

The only note is that if you choose to build "samples" with both versions they will collide as they are unversioned, but I doubt we need to care about that as its just the samples and I'm not sure why you would need samples from each version.

ffontaine commented 7 years ago

Thanks for testing, the PR #17 renames all test, unittest and sample programs.

whyman commented 7 years ago

After a patch to update the search and include paths, all is good!

$ ldd mediatomb | grep upnp
        libupnp-1.8.so.10 => /usr/lib64/libupnp-1.8.so.10 (0x00007fb0de8e1000)
whyman commented 7 years ago

Happy new year guys! Any update on getting 1.8 out the door?

mrjimenez commented 7 years ago

Tagged!

whyman commented 7 years ago

Awesome! Should we take the tarballs from https://github.com/mrjimenez/pupnp/releases/tag/release-1.8.0 as the release tarballs?

ffontaine commented 7 years ago

I think you can. Perhaps, we should also update the sourceforge website? I also added some release notes and tag this release as "pre-release":

This is the first pre-release of the 1.8.x branch of pupnp. The API of this branch is not backward compatible with the 1.6.x branch. So, to avoid breaking existing applications which depend on the usual 1.6.x API, the 1.8.x branch will:

  • install its headers into the upnp-1.8 subdirectory
  • add the "-1.8" suffix to its library names (for example libupnp-1.8.so), its pkgconfig file (libupnp-1.8.pc) or its samples (for example tv_ctrlpt-1.8)

For the time being, both branches will continue to be maintained.