On Mon, Nov 2, 2015 at 7:57 PM, Ronald S. Bultje <rsbul...@gmail.com> wrote: > Hi, > > On Mon, Nov 2, 2015 at 12:32 PM, Ganesh Ajjanagadde <gajja...@mit.edu> > wrote: > >> On Mon, Nov 2, 2015 at 11:58 AM, Ronald S. Bultje <rsbul...@gmail.com> >> wrote: >> > Hi, >> > >> > On Mon, Nov 2, 2015 at 11:07 AM, Ganesh Ajjanagadde <gajja...@mit.edu> >> > wrote: >> > >> >> On Mon, Nov 2, 2015 at 10:28 AM, Ronald S. Bultje <rsbul...@gmail.com> >> >> wrote: >> >> > Hi, >> >> > >> >> > On Sun, Nov 1, 2015 at 8:20 PM, Ganesh Ajjanagadde <gajja...@mit.edu> >> >> wrote: >> >> > >> >> >> On Sun, Nov 1, 2015 at 7:59 PM, Ronald S. Bultje <rsbul...@gmail.com >> > >> >> >> wrote: >> >> >> >> >> >> - I think the name of this function is confusing. The av_clip* >> namespace >> >> >> > seems reserved for int to int clips, so using it for a float to int >> >> >> > conversion with clip is kind of weird. I would use a different >> >> namespace >> >> >> > for it. >> >> >> >> >> >> Mathematically, it is the same as clipping, albeit "lossy", but then >> >> >> again all clipping is by nature "lossy" on inputs outside the >> clipping >> >> >> range, hence the choice of name. Any ideas for a namespace for this? >> >> >> >> >> > >> >> > Clip is the namespace for _just_ a clip. This function converts _and_ >> >> > clips. How about av_rint64_clip. >> >> >> >> I like this name, thanks. Also, please tell me what to do about >> >> version bumps etc, so that I can get this done for v2. >> > >> > >> > I'm not sure actually. >> > >> > I believe for new API you increment minor (see libavutil/version.h) by 1 >> > and reset micro to 0. You bump major on API changes, and you bump micro >> for >> > behavioural changes (?). >> >> Hmm, then there is a micro bump that I missed: av_gcd works >> differently for negative inputs than before: previously it was >> undefined in terms of its documentation, not actuality I believe, but >> now it has well defined semantics for all int64_t, and this has been >> documented. > > > A micro does not have to be bumped on the very commit. We can merge that > micro-bump together for various features, or we can forget it altogether > and it's simply part of the next (totally unrelated) microbump. You can > even bump it today if there has not been a bump since already. > > Regardless of when the micro was bumped after the fact, the application > that relies on the new/fixed/changed behaviour can then use that micro as > minimum required runtime version. That this was committed a month later is > merely a detail that most users will never know or care for. >
We don't really bump micro in the majority of cases anyway, not every bugfix or change needs a bump. Its more important to remember to bump minor when adding new API or similar, so people can use that version to know if its present. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
