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 115 forks source link

Missing release #131

Closed ePirat closed 4 years ago

ePirat commented 4 years ago

The Readme lists a v1.12.0 release on 2019-11-29, but there is no such release.

ePirat commented 4 years ago

Additionally it would be great if you could create "proper" Github releases for:

so that they show up on the releases page.

mrjimenez commented 4 years ago

The Readme lists a v1.12.0 release on 2019-11-29, but there is no such release.

Yes, we had an issue with an API breakage and the list.h stuff. Seems to be ready for release, I am just waiting for Ian to tell us if it is ok, it would be nice if gerbera works fine with the new 1.12.x branch. I have changed the date to TBA.

Additionally it would be great if you could create "proper" Github releases for:

  • release-1.8.4
  • release-1.8.5
  • release-1.10.0
  • release-1.8.6
  • release-1.10.1

so that they show up on the releases page.

Done.

ePirat commented 4 years ago

@mrjimenez Can you wait with the release a little bit, then? If we anyway break API, we might break it a bit more to remove things like the TRUE and FALSE stuff and use proper stdbool.h?

ghost commented 4 years ago

The list changes only affect programs using the very recent list feature (and not always, I don't think that Gerbera is going to need a source change).

Removing the TRUE def is going to break programs depending on it for no good reason at all.

By all means, use stdbool.h in your new code, but do not gratuitously break old working code.

ePirat commented 4 years ago

IMO the good reason is that a library has no business defining non-namespaced macros like TRUE and FALSE at all. If your code needs that you can just define them yourself, so I don't see the a huge impact this would have on existing code.

jbkempf commented 4 years ago

Removing the TRUE def is going to break programs depending on it for no good reason at all.

Are you seriously suggesting it is a good idea for a library to define TRUE and FALSE? True and false are reserved identifiers in quite a few C compatible languages....

ghost commented 4 years ago

This library is around 15 years old. There are probably programs around that still depend on it which have not changed for many years.

You do not make change in working code because you feel like it.

TRUE and FALSE (capitals) have never been reserved words in C or C++ (or please, be more specific if you can prove otherwise).

Using these defines in a new library, or in new code using libupnp would be a mistake.

Removing them from the existing API just for cosmetic reasons would be another mistake.

jbkempf commented 4 years ago

This library is around 15 years old. There are probably programs around that still depend on it which have not changed for many years.

This is why those are major versions, with API and ABI breaks. Old apps stay on old version of the libraries. New ones adapt to the new APIs, like for absolutely every library ever.

Removing them from the existing API just for cosmetic reasons would be another mistake.

Cosmetic reasons? This is a joke, right? You advocate for defining things like TRUE, FALSE and BOOL?

libupnp has been a pain for years, reinventing the wheel, with its own xml library, its own threading library, and lots of quirks on networking, not being thread-safe and so many other issues.

It's finally evolving again, and we're grateful, but advocating against evolution is totally backwards...

alexandre-janniaux commented 4 years ago

This library is around 15 years old. There are probably programs around that still depend on it which have not changed for many years.

I get the same feeling than jbkempf. People using 15 years old software code depending on this library will probably not try to upgrade and are not running a desktop station. Doing a major release breaking this shouldn't break them except if their process are also broken, because there would be a lot of other reason to break than removing this otherwise.

Fixing other people mistake and code in your own library feels backward and is a way to create more broken program depending on this behaviour.

Maybe a survey can be made on the major comtemporary users of this library to check whether they are concerned or not before landing the change ?

ghost commented 4 years ago

Still waiting for how TRUE and FALSE are reserved words by the way.I don't depend on these defines, just being altruistic here. Wasting my time here, please proceed.

jbkempf commented 4 years ago

I don't depend on these defines, just being altruistic here.

You meant trolling for the sake of trolling? Very good. You raise an objection for something that you don't even know people depend on...

So you are altruistic to people that you don't even know that exists, that depend on old behavior, and you refuse that other people fix those weird things, when there is already an API and ABI breakage? And you justify that by telling that it was like that 15years ago...

ghost commented 4 years ago

To keep the record straight: I don't think that we have an API issue at this point. Maybe I'm wrong, but we have some reasons to believe that Gerbera is the only user of the ExtraHeaders code, and, quite by luck, and as far as I could see, no breakage there.

You seem to be unsure about the definition of trolling though. Here is some help: https://www.urbandictionary.com/define.php?term=Trolling

mrjimenez commented 4 years ago

C'mon guys, stop the crap, please. There is absolutely no point in being rude here, so lets start again, ok?

I understand both points of view and both are valid. BUT I tend to prefer libraries that do not define excessive simple things like TRUE or FALSE, this is usually a bad thing because clashes with other bad designed libraries.

If any user of this library is willing to update, he/she will have to do more complex stuff than replacing TRUE or FALSE, so I am all in for removing it from the public API.

mrjimenez commented 4 years ago

@mrjimenez Can you wait with the release a little bit, then? If we anyway break API, we might break it a bit more to remove things like the TRUE and FALSE stuff and use proper stdbool.h?

Should we release now? It has been a while...

ePirat commented 4 years ago

Do we want to clean up some of the ignored parameters in APIs, that were only left there for compatibility but are unused?

mrjimenez commented 4 years ago

Since this is a major release, and since we broke stuff, I see no problem if we do it now right at the start. But as always, I would like to hear opinions.

ePirat commented 4 years ago

Well, if we do we it, we need to do it now before the release as that will be the release that breaks API/ABI anyway, doing it later would mean these changes need to wait for a next API/ABI breaking "big" release, which ideally happen as rarely as possible, IMO.