search

ljubobratovicrelja / ffmpeg-d

D port of the FFmpeg C headers
16 stars 9 forks source link

ffmpeg-d project versioning #5

Open DavidBennettPIO opened 8 years ago

DavidBennettPIO commented 8 years ago

Hey, I've started work on porting the headers over from 3.0.2 and I was just wondering what should happen with the version of this project. I don’t really was to push a breaking change to master right now for obvious reasons.

I think we should be matching the major.minor but have our own patch from ffmpeg so users know what to use and can set the correct version in dub.

Also it would be nice to have separate branches in this repo for each version so we can add changes to older releases. (2.8 will probably hang around for a while)

So what I propose is matching the main ffmpeg repo by adding these branches added to this repo:

And then in the readme for each branch state what version it applies to and the fact that other branches are available with a code snipit on how to add to dub and lock the major.minor version.

So something like this:

NOTE: This branch is compatible with ffmpeg 3.0.x, for other versions please see the other branches for usage information.

To include ffmpeg-d in your dub project add the following dependency to your dub.json file.

"ffmpeg-d": "~>3.0.0"

What are your thoughts?

Also, feel free to have a read through my 3.0.2 port at https://github.com/complistic-gaff/ffmpeg-d/commit/ccb16d2c90210de973d40b0b8ad5894de02e30c0 I still need to test this out well, If I have time I might even write some simple examples.

Thanks!

ljubobratovicrelja commented 8 years ago

First of all, thanks for taking interest in helping out! :)

I think we should be matching the major.minor but have our own patch from ffmpeg so users know what to use and can set the correct version in dub.

I agree. There were multiple cases where people where trying to use ffmpeg-d 2.5.0 with FFmpeg 3.x libs. There should be some correlation with those versions, to make it more obvious. And yes, using patch number as ffmpeg-d's refinement (iteration) version seems like a smart thing to do. I don't see anything wrong, nor do I have a better idea.

So what I propose is matching the main ffmpeg repo by adding these branches added to this repo

I also agree here. So, now I could branch out from current master as release/2.8, so 3.0 development could be ran on master. When we start working on 3.1, we can branch out release/3.0 from master, and use master for 3.1 development, and so on. In other words, master should always represent binding development of the latest supported FFmpeg major.minor version. Does that sound fair?

Also, feel free to have a read through my 3.0.2 port at complistic-gaff@ccb16d2 I still need to test this out well, If I have time I might even write some simple examples.

Cool! Once I branch out release/2.8 feel free to make a PR to master with your changes.

So, how about following course of action?

Sounds good?