#5226 closed defect (invalid)
libavcodec micro version no longer 100
Reported by: | jyavenard | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | avcodec |
Version: | unspecified | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
In bug #5057, Michael suggested to use the libavcodec micro version of 100 as a way to differentiate between LibAV and FFmpeg.
However:
commit ae5b2c52501d5009fe712334428138a9b758849b Author: foo86 <foobaz86@gmail.com> Date: Sat Jan 16 11:54:38 2016 +0300 avcodec/dca: add new decoder based on libdcadec
made the micro version 101 rather than bumbing the minor version.
Can the micro version be reset to 100 and minor version bumped?
Thank you.
Change History (8)
comment:1 by , 8 years ago
follow-up: 7 comment:2 by , 8 years ago
Actual comment was:
"FFmpeg will always have a micro version over 100, while Libav starts at 0. Doing this in binary is probably rather painful, but no more painful than supporting 56 and 57 in parallel either way."
I see another comment stating 100 and over though
comment:3 by , 8 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
Yes, FFmpeg is ≥100, Libav is ≥0. Technically Libav can go over 100, but it has never in my memory exceeded 10.
comment:4 by , 8 years ago
Resolution: | invalid |
---|---|
Status: | closed → reopened |
22:50 <@Timothy_Gu> jya: you can test MINOR >= 100 22:51 <@Timothy_Gu> *MICRO 22:52 < jya> Timothy_Gu: sure... I opened ticket 5226. Problem for us is that we're riding the train and if a 2.9 version comes out with that, it will break our FFmpeg support for 12 weeks. 22:54 < jya> so knowing that a new version will likely come for ubuntu 16.04, our release cycle may be causing issue. so much easier to have this changed in ffmpeg :) and also document that it won't happen again (can see someone resetting to 0 the way it currently is documented) 22:54 <@Timothy_Gu> jya: you mean you can't push a trivial patch like this to your release branch? 22:54 < jya> that's right [...] 22:57 <@Timothy_Gu> regardless, I don't think it is reasonable to make sure ffmpeg doesn't bump micro for 12 weeks 22:58 < jya> Timothy_Gu: we should make sure it never goes under 100 though 22:58 < jya> so that itself that worth a ticket so version.h is documented as such
comment:5 by , 8 years ago
Resolution: | → invalid |
---|---|
Status: | reopened → closed |
Even if it was stated that the version will always be 100, this was a mistake and it is fixed now: The version will always be >=100.
follow-up: 8 comment:6 by , 8 years ago
It would be good to add a note in libavcodec/version.h and put a note that micro is to never go < 100.
comment:7 by , 8 years ago
Replying to jyavenard:
"FFmpeg will always have a micro version over 100
Sorry but I'd like to add that this definitely doesn't mean FFmpeg micro version will always be 100.
comment:8 by , 8 years ago
Replying to jyavenard:
It would be good to add a note in libavcodec/version.h and put a note that micro is to never go < 100.
If such note is added then it should be added to version.h of libavutil, libavdevice, libavfilter, libswresample, libpostproc, libswscale too
Maybe comment to never touch the micro version would be good for the future so this doesn't happen again.