[libdvdcss-devel] Next release will be 1.2.13

[Jean-Baptiste Kempf]

libdvdcss | branch: master | Jean-Baptiste Kempf <***@videolan.org> | Thu Feb 14 22:59:20 2013 +0100| [45999b756e2b6491eabcd548f7eb1453ab7fb365] | committer: Jean-Baptiste Kempf

Next release will be 1.2.13

http://git.videolan.org/gitweb.cgi/libdvdcss.git/?a=commit;h=45999b756e2b6491eabcd548f7eb1453ab7fb365

---

configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 4b9349c..1019e40 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,4 +1,4 @@
-AC_INIT(libdvdcss, 1.2.12)
+AC_INIT(libdvdcss, 1.2.13)
AC_CONFIG_SRCDIR([src/libdvdcss.c])

AC_PREREQ(2.50)

[Diego Elio Pettenò]

Post by Jean-Baptiste Kempf
Next release will be 1.2.13

So speaking about next release, I would suggest a couple of things for 1.3:

- some symbols exported by the current .so.2 library are not declared
in the header files at all; since the libdvdcss consumers are relatively
known, and few, I'd suggest we check whether they are using them at all,
and if not remove them;

- the cache... let's start by dropping support for the CACHETAG stuff
which is ancient and nobody follows anyway; I would vote for removing
the cache entirely (the thing backfired on me at least in one occasion,
while I developed xine, because on a tv series set of dvds it would
calculate more than one with the same name... and obviously the keys
were different), but I know j-b is not up for that.

I'd suggest to cut it down to just support the XDG-style cache on
Linux/Unix — and do whatever you want with Windows. I could also suggest
to use libxdg-basedir, but it would probably be a bit of overkill...
(xine uses it).

[Diego Biurrun]

Post by Diego Elio Pettenò

Post by Jean-Baptiste Kempf
Next release will be 1.2.13

- some symbols exported by the current .so.2 library are not declared
in the header files at all; since the libdvdcss consumers are relatively
known, and few, I'd suggest we check whether they are using them at all,
and if not remove them;

+1

Post by Diego Elio Pettenò
- the cache... let's start by dropping support for the CACHETAG stuff
which is ancient and nobody follows anyway; I would vote for removing
the cache entirely (the thing backfired on me at least in one occasion,
while I developed xine, because on a tv series set of dvds it would
calculate more than one with the same name... and obviously the keys
were different), but I know j-b is not up for that.

I believe the cache is useful. Cracking keys takes some time on machines
otherwise fast enough to play DVDs...

Post by Diego Elio Pettenò
I'd suggest to cut it down to just support the XDG-style cache on
Linux/Unix — and do whatever you want with Windows. I could also suggest
to use libxdg-basedir, but it would probably be a bit of overkill...
(xine uses it).

Why not?


I also suggest having a hard look at the rest of the codebase and excising
cruft, plus possibly change APIs. Here are some ideas:

- There is some #if 0 code of doubtful utility.
- All of src/error.c looks bogus and unused.
- I personally find the changelog file generated from git rather silly.
- There is some private namespace invasion (names starting with _ and
ending in _t).
- What's with all the silly forward declarations?
- Anybody against running everything through uncrustify?

Diego