New release?

[pupnp]

New release?

[ukleinek]

If @v00d00 gets a cookie, I request one, too :-)
(SCNR)

[mrjimenez]

Hi,

If you have the opportunity, please review the current master and 1.8 branches. On my side, we can do two releases by the end of next week.

I really don't know if the libtool numbers of 1.10.0 are ok. I would like to discuss it before release as this is traditionally a big source of problems.

Regards,
Marcelo.

[tmottabr]

any info on when the next version will be released? users of gerbera are waiting for it for gerbera to work with samsung tvs. it required a patch that is only on master.

Hi,

As far as I can see, the 1.8 branch is working fine, and I am all for releasing 1.8.5.

The master branch has a source-level incompatibility, because of the additional parameter to the virtualdir callbacks, so releasing it would break any application currently using the virtual directory interface.

By the way, some of the related changes break the indentation (using 4 spaces instead of a tab). I don't care one way or another, but it would be better to keep it consistent and libupnp has always used tabs.

Also the SendInstruction struct was not always fully initialized, I just submitted a small pull request.

Other than that, both branches seem to work fine for me :)

[mrjimenez]

Sorry for that, I had not pushed the tags and had not not put the sources on sourceforge.

Thank you for reminding me.

Best regards,
Marcelo.

[whyman]

Or 1.9 ideally!

[mrjimenez]

Hi Ian, which patch do you want to merge? If already merged, you just want a new release? I am sorry I somehow lost track of this issue.

[whyman]

Haha no worries -- it is already merged to master, the one for "Request Cookies"

[mrjimenez]

Ok, lets release.

Ian, if I am not mistaken, your patch in only on master, not on 1.8. So we could do two releases, a 1.8.5 and a 1.10.0 on master. Normally we skip odd releases because a long time ago odd middle numbers were development releases. But I am not so attached to this, so If you think this policy is deprecated, we can go for 1.9.0 on master.

I have a configure.ac ready for 1.8, I will commit it for your review (libtool stuff). As soon as we agree on the name of the master release, I will do the same for master. Then it is cookies for all that committed. :)

Marcelo Roberto Jimenez writes: Hi, If you have the opportunity, please review the current master and 1.8 branches. On my side, we can do two releases by the end of next week. Hi, I see no obvious problem with branch 1.8, it has been stable for some time. I really don't know if the libtool numbers of 1.10.0 are ok. I would like to discuss it before release as this is traditionally a big source of problems. For 1.8, I suppose that this comment in the git log means that an interface was added ? Promote ExtraHeaders to a public API As far as I can see, none were changed or deleted (Yeah !) Cheers, jf

[mrjimenez]

The problem is that if we do not break the interface, even if virtually, we may end up with 1.8.x having the same numbers as 1.10.x. Creating this new branch effectively prohibits adding interfaces to 1.8.

At least that is how I understand it, but I really don't know, I would like to hear from someone who packages before hearing the complaints :)

Cheers!

Marcelo Roberto Jimenez writes: The problem is that if we do not break the interface, even if virtually, we may end up with 1.8.x having the same numbers as 1.10.x. Creating this new branch effectively prohibits adding interfaces to 1.8. We should not add interfaces to 1.8 because it would mean that you can't know if you can port between two distributions having pupnp 1.8: you would need to look at the 3rd number, which would be really bad. Compatibility between 1.8.x and 1.8.y must be for source and binary, and be bidirectional. Some interfaces changed in 1.10, which you indicated by bumping current from 14 to 15 and setting age to 0. So 1.8.z libs will remain at libupnp.so.13, and 1.10.z ones will start at libupnp.so.15 If we agree that nothing should be changed or removed in the 1.8 interface (I hope we do), and at the very worse, if something was added to it (I hope not), you would increment current and age, and the .so number would remain 13. At least that is how I understand it, but I really don't know, I would like to hear from someone who packages before hearing the complaints :) Yes, definitely, let the packagers be heard ! jf

[ukleinek]

The problem is that if we do not break the interface, even if virtually, we may end up with 1.8.x having the same numbers as 1.10.x. Creating this new branch effectively prohibits adding interfaces to 1.8.

At least that is how I understand it, but I really don't know, I would like to hear from someone who packages before hearing the complaints :)

With my Debian packager's hat on, I don't have a problem changing the API without the change of the version. The important restriction is that the library versioning (which has little connection to the version number of the project) is done right. If you are motivated to learn something, I recommend reading "How To Write Shared Libraries" by Ulrich Drepper (Chapter 3 is the interesting one here).
TLDR: Adding a new function to libupnp 1.8.x is fine iff a program that makes use of the new function fails to run if a too old function is used. The Debian tools are able to manage that just fine, and even emit a less strong dependency on libupnp when the program doesn't make use of the new function.

Best regards
Uwe

[mrjimenez]

Hi Uwe,

I really do appreciate your comments and I will certainly take a look at the document about shared libraries. But right now I am worried about an immediate naming problem. I don't know how things are done in Debian, I am sure it must be done in a smart way. But here is the situation in Opensuse Tumbleweed:

# rpm -qa | grep -i libupnp
libupnp13-1.8.4-2.5.x86_64
# rpm -ql libupnp13-1.8.4 | less
/usr/lib64/libupnp.so.13
/usr/lib64/libupnp.so.13.0.0
/usr/share/doc/packages/libupnp13
/usr/share/doc/packages/libupnp13/ChangeLog
/usr/share/licenses/libupnp13
/usr/share/licenses/libupnp13/COPYING

The "13" in the name refers to libtool's "current" number. The binary file libupnp.so.13.0.0 does not reflect the fact that it is a 1.8.x branch. So, libupnp 1.8.4 is "13.0.1", while libupnp 1.8.5 will be "14.0.1", meaning that 1.8.5 supports interfaces 14 and 13. What I called "virtually breaking interface" maybe would have been better called "artificially breaking the interface". Why I did that? Yes, the last patch does exactly that in case you did not see, but notice that we still did not release, so there is time to fix it. What would be the numbers for 1.10.0? Easy because interfaces were added. But the base for 1.10.0 is 1.8.4, not 1.8.5. Abstract the fact that we are doing this release simultaneously and pretend that we are releasing 1.10.0 before 1.8.5. Then libupnp 1.10.0 will be "14.0.1". As a consequence, the library file names will be the same upstream. The packagers will need to do some magic if they want to install two different versions of the library at the same time, which is something my experience tells me they often do, please correct me if I am wrong.

In summary, what I am trying to say is that in my current opinion, which is subject to change, of course, we should artificially break linking compatibility of libupnp 1.10.0 by making it be "15.0.0" instead of "14.0.1", and never again messing with 1.8.x interfaces so that "current" never gets bumped up again. Otherwise we risk having library files in different branches with the same name, which is likely a packager's nightmare.

What do you think folks?

Regards,
Marcelo.

Here is upnp port's maintainer for FreeBSD.

I am a bit confused about what the issue is (this might be because I am not native English speaker), but if I understood well you are worried about the possibility that maintainers/packagers might want to have different versions of libupnp in the repositories simultaneously and how should they do it.
In particular, it seems that you want to release two different versions: 1.8.5 and 1.10.0.
Please do not do that: choose a version and stick to it.

The problem is that if you have two different versions, both supported but incompatible (like it seems to me you want to do), some software will be developed with one version while other software will be developed with the other. That means that packagers will have to maintain both versions in their systems repository, which is very annoying, and the more the library is used the more it is annoying: see the python case.
In the python case, at least in FreeBSD, we always have to maintain and almost always to install two versions (2.7 and 3.6; maybe now the latter is 3.7) precisely for this reason, although many of our users (me for example) would like to install python only once.

Moreover, at least in my community, for this very reason there is some resistance in supporting multiple versions. See for example my precedent update of the upnp port:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234669

Lorenzo Salvadore.

[tmottabr]

The extra headers patch in pull request #98 i refereed to is merged to master, if this can be merged back to 1.8 branch than a 1.8.5 release would suffice.

Please check, but as far as I can see, the patch is already in 1.8.

[tmottabr]

You are correct. I had not checked that branch. Then i believe that a 1.8.5 release will enough.

[mrjimenez]

Just did the releases.

Regards,
Marcelo.

[ffontaine]

Hi @mrjimenez, I don't see 1.8.5 on github or sourceforge, did I missed something?