gstreamer-1.x

[nponeccop]

I have a port of few modules from Core/ to 1.x version, as 0.x is officially unmaintained since May. I ported only the functions necessary for my project.

I also implemented few previously unimplemented functions and data structures for pads and probes.

Should I release the code? What is the best way?

[hamishmack]

Yes it would be cool to get that updated. I don't think it matters if it is just the functions you needed. The best way might be to fork the repo and send a pull request. I'll merge it and put it into hackage.

[nponeccop]

A little problem is that those modules I didn't port cannot be compiled with 1.x.

So the plan could be to have 0.12.x with full set of modules and 1.x with only few modules (but still enough to be usable) on Hackage.

Also .cabal had to be modified to include different pkg-config dependencies. And the hierarchy files.

Do you think it's possible to release separate 1.x package version with different source tree?

.hs files do support conditional compilation so for them we can easily have single codebase. What about .cabal and hierarchy?

Another possible approach is not to release anything to hackage yet, but incorporate my code in current .hs files as the first step to 1.x. So few files will be compatible with 1.x and less work will be required in the future.

What do you think?

[hamishmack]

Sounds like it might be a similar problem to what we have with gtk/gtk3 and gtksourceview2/gtksourceview3. For those we have a new .cabal file and have changed the old one to .cabal-renamed (so it is normally ignored by cabal). That way we can have two packages in hackage, but just one git repo. We tried both cabal flags and having different cabal versions, but it made it harder to install both of them at the same time. I think it is a good idea to have two hackage repos whenever there are typically separate pkg-config files (as I believe is the case here). Please take a look at the gtksourceview repo and see if that approach would make sense here.

[sdroege]

For GStreamer 1.x it might be best to generate the bindings automatically via gobject-introspection though. That should be much more convenient and will keep the maintenance burden lower.

[nponeccop]

I actually thought that existing bindings were generated this way, But it seems the amount of introspection used is quite low and most is handwritten.