| Message ID | 20230116133840.512-1-jamrial@gmail.com |
|---|---|
| Headers | show |
| Series | Major library version bump | expand |
Quoting James Almer (2023-01-16 14:38:14) > It's been a while since the last bump, so it's time to do some cleaning and > remove deprecated APIs. This will also give us an "Open ABI season" in which we > can do breaking changes (like changing public struct offsets, public enum > values, adding fields to structs that have their size tied to the ABI, etc) for > a few weeks. Last time this open season lasted something like half a year and only ended when I arbitrarily said it did. So I'd suggest to decide right now how long will the instability period last (6 weeks should be enough for everybody) and write the end date at the top of doc/APIchanges. Another thing I'm not entirely happy about is versioning during the bump and instability. While the remove-then-bump approach does make bisection easier, it also creates commits that lie about their ABI version. I wonder if we couldn't come up with a better soltion. One thing that comes to mind is setting the major version to 0 until the instability period ends. > I'm also taking this opportunity to suggest a change in our deprecation period > policy. Until now it's been a generic two years period, with no concrete reason > for it other than giving library users "time" to migrate. What we have seen > however is that users migrate in two cases: As soon as things are deprecated > when they use git head to get rid of deprecation warnings, or when they have no > choice (aka, when they want to move their project to a new ffmpeg version that > no longer has the symbols they depended on). > In the latter case, any arbitrary amount of time will make no difference > whatsoever. Projects could right now still be using ffmpeg 4.3 (since that's > what Debian stable ships) and would not consider moving to 5.1 or any future > version for the foreseeable future. So the suggestion is to change to a release > based scheme, which will in some form be time based anyway. Namely, every three > releases we do a major bump, which will be a good year or so in real world > terms, in which all API deprecated during that period, as long as it's present > in a release, is removed. This would also go with the idea of a recurrent LTS > release, so if we do three releases per major version, it could be x.0 (initial > release) x.1 (LTS), and x.2 (last release made pre bump). Sounds good to me. > If we go the above route, we could also remove API like the old lavu FIFO stuff, > a deprecation that's slightly less than a year old but effectively present in > v5.1. > We'd also need to add all this in writing, because this kind of policy can't > just be "oh yeah, we do it that way" in random emails. But folklore is the most time-tested method of transmitting information.
On 1/18/2023 4:28 PM, Anton Khirnov wrote: > Quoting James Almer (2023-01-16 14:38:14) >> It's been a while since the last bump, so it's time to do some cleaning and >> remove deprecated APIs. This will also give us an "Open ABI season" in which we >> can do breaking changes (like changing public struct offsets, public enum >> values, adding fields to structs that have their size tied to the ABI, etc) for >> a few weeks. > > Last time this open season lasted something like half a year and only > ended when I arbitrarily said it did. > > So I'd suggest to decide right now how long will the instability period > last (6 weeks should be enough for everybody) and write the end date at > the top of doc/APIchanges. > > Another thing I'm not entirely happy about is versioning during the bump > and instability. While the remove-then-bump approach does make bisection > easier, it also creates commits that lie about their ABI version. Does it really matter? All the patches will be pushed at the same time, meaning one git fetch will give you a stable state pre bump and the next will be right after it. I think it's a bit farfetched to expect someone to pick a random commit in the middle of the bump and try to use the resulting compiled libraries with some program that was linked to some earlier version libraries. > > I wonder if we couldn't come up with a better soltion. One thing that > comes to mind is setting the major version to 0 until the instability > period ends. This could have several undesired effects, mainly for users looking at that define and not really expecting such value (There are several projects supporting more than one ffmpeg release and "MAJOR <= xx" checks are commonplace). Also, if we are going to code the instability period in some form into the codebase, might as well make it so it starts with the first removal commit, or immediately before it, so what you described above is no longer a concern. > >> I'm also taking this opportunity to suggest a change in our deprecation period >> policy. Until now it's been a generic two years period, with no concrete reason >> for it other than giving library users "time" to migrate. What we have seen >> however is that users migrate in two cases: As soon as things are deprecated >> when they use git head to get rid of deprecation warnings, or when they have no >> choice (aka, when they want to move their project to a new ffmpeg version that >> no longer has the symbols they depended on). >> In the latter case, any arbitrary amount of time will make no difference >> whatsoever. Projects could right now still be using ffmpeg 4.3 (since that's >> what Debian stable ships) and would not consider moving to 5.1 or any future >> version for the foreseeable future. So the suggestion is to change to a release >> based scheme, which will in some form be time based anyway. Namely, every three >> releases we do a major bump, which will be a good year or so in real world >> terms, in which all API deprecated during that period, as long as it's present >> in a release, is removed. This would also go with the idea of a recurrent LTS >> release, so if we do three releases per major version, it could be x.0 (initial >> release) x.1 (LTS), and x.2 (last release made pre bump). > > Sounds good to me. > >> If we go the above route, we could also remove API like the old lavu FIFO stuff, >> a deprecation that's slightly less than a year old but effectively present in >> v5.1. >> We'd also need to add all this in writing, because this kind of policy can't >> just be "oh yeah, we do it that way" in random emails. > > But folklore is the most time-tested method of transmitting information. >
Quoting James Almer (2023-01-18 22:23:43) > On 1/18/2023 4:28 PM, Anton Khirnov wrote: > > Quoting James Almer (2023-01-16 14:38:14) > >> It's been a while since the last bump, so it's time to do some cleaning and > >> remove deprecated APIs. This will also give us an "Open ABI season" in which we > >> can do breaking changes (like changing public struct offsets, public enum > >> values, adding fields to structs that have their size tied to the ABI, etc) for > >> a few weeks. > > > > Last time this open season lasted something like half a year and only > > ended when I arbitrarily said it did. > > > > So I'd suggest to decide right now how long will the instability period > > last (6 weeks should be enough for everybody) and write the end date at > > the top of doc/APIchanges. > > > > Another thing I'm not entirely happy about is versioning during the bump > > and instability. While the remove-then-bump approach does make bisection > > easier, it also creates commits that lie about their ABI version. > > Does it really matter? All the patches will be pushed at the same time, > meaning one git fetch will give you a stable state pre bump and the next > will be right after it. > I think it's a bit farfetched to expect someone to pick a random commit > in the middle of the bump and try to use the resulting compiled > libraries with some program that was linked to some earlier version > libraries. I agree that it's probably not a big practical problem, but it is ugly and goes against our claims of git master being stable. > > I wonder if we couldn't come up with a better soltion. One thing that > > comes to mind is setting the major version to 0 until the instability > > period ends. > > This could have several undesired effects, mainly for users looking at > that define and not really expecting such value (There are several > projects supporting more than one ffmpeg release and "MAJOR <= xx" > checks are commonplace). IMO users who don't expect such a value shouldn't be linking against unstable API/ABI anyway. We could also set the major version to something really big, like 999. We'll have to change deprecation macros, but that should be straightforward. > Also, if we are going to code the instability period in some form into > the codebase, might as well make it so it starts with the first removal > commit, or immediately before it, so what you described above is no > longer a concern. I'd rather say the two concerns merge into one, but it's not going away. There's currently very little user indication that API/ABI are unstable for several months.
On 1/19/2023 4:26 AM, Anton Khirnov wrote: > Quoting James Almer (2023-01-18 22:23:43) >> On 1/18/2023 4:28 PM, Anton Khirnov wrote: >>> Quoting James Almer (2023-01-16 14:38:14) >>>> It's been a while since the last bump, so it's time to do some cleaning and >>>> remove deprecated APIs. This will also give us an "Open ABI season" in which we >>>> can do breaking changes (like changing public struct offsets, public enum >>>> values, adding fields to structs that have their size tied to the ABI, etc) for >>>> a few weeks. >>> >>> Last time this open season lasted something like half a year and only >>> ended when I arbitrarily said it did. >>> >>> So I'd suggest to decide right now how long will the instability period >>> last (6 weeks should be enough for everybody) and write the end date at >>> the top of doc/APIchanges. >>> >>> Another thing I'm not entirely happy about is versioning during the bump >>> and instability. While the remove-then-bump approach does make bisection >>> easier, it also creates commits that lie about their ABI version. >> >> Does it really matter? All the patches will be pushed at the same time, >> meaning one git fetch will give you a stable state pre bump and the next >> will be right after it. >> I think it's a bit farfetched to expect someone to pick a random commit >> in the middle of the bump and try to use the resulting compiled >> libraries with some program that was linked to some earlier version >> libraries. > > I agree that it's probably not a big practical problem, but it is ugly > and goes against our claims of git master being stable. > >>> I wonder if we couldn't come up with a better soltion. One thing that >>> comes to mind is setting the major version to 0 until the instability >>> period ends. >> >> This could have several undesired effects, mainly for users looking at >> that define and not really expecting such value (There are several >> projects supporting more than one ffmpeg release and "MAJOR <= xx" >> checks are commonplace). > > IMO users who don't expect such a value shouldn't be linking against > unstable API/ABI anyway. We could also set the major version to > something really big, like 999. We'll have to change deprecation macros, > but that should be straightforward. > >> Also, if we are going to code the instability period in some form into >> the codebase, might as well make it so it starts with the first removal >> commit, or immediately before it, so what you described above is no >> longer a concern. > > I'd rather say the two concerns merge into one, but it's not going away. > There's currently very little user indication that API/ABI are unstable > for several months. How about making minor == 0 mean unstable? Some projects like GCC do it like this, for example. Said version would not guarantee anything at all and should not be linked against. Then once the period ends after the major bump, it's bumped to 1, and the usual "new API, minor bump" rule kicks in. This also means that any API addition that takes place during the unstable period doesn't get it's own version, and they will all strictly speaking be introduced by minor 1. As for your concern about first removing then bumping meaning we're lying about the ABI, the first commit in the set could maybe rollback minor to 0, then apply the removals, and finally the major bump in the last commit. It will that way be considered unstable for the whole thing.
Quoting James Almer (2023-01-19 13:18:28) > On 1/19/2023 4:26 AM, Anton Khirnov wrote: > > Quoting James Almer (2023-01-18 22:23:43) > >> On 1/18/2023 4:28 PM, Anton Khirnov wrote: > >>> Quoting James Almer (2023-01-16 14:38:14) > >>>> It's been a while since the last bump, so it's time to do some cleaning and > >>>> remove deprecated APIs. This will also give us an "Open ABI season" in which we > >>>> can do breaking changes (like changing public struct offsets, public enum > >>>> values, adding fields to structs that have their size tied to the ABI, etc) for > >>>> a few weeks. > >>> > >>> Last time this open season lasted something like half a year and only > >>> ended when I arbitrarily said it did. > >>> > >>> So I'd suggest to decide right now how long will the instability period > >>> last (6 weeks should be enough for everybody) and write the end date at > >>> the top of doc/APIchanges. > >>> > >>> Another thing I'm not entirely happy about is versioning during the bump > >>> and instability. While the remove-then-bump approach does make bisection > >>> easier, it also creates commits that lie about their ABI version. > >> > >> Does it really matter? All the patches will be pushed at the same time, > >> meaning one git fetch will give you a stable state pre bump and the next > >> will be right after it. > >> I think it's a bit farfetched to expect someone to pick a random commit > >> in the middle of the bump and try to use the resulting compiled > >> libraries with some program that was linked to some earlier version > >> libraries. > > > > I agree that it's probably not a big practical problem, but it is ugly > > and goes against our claims of git master being stable. > > > >>> I wonder if we couldn't come up with a better soltion. One thing that > >>> comes to mind is setting the major version to 0 until the instability > >>> period ends. > >> > >> This could have several undesired effects, mainly for users looking at > >> that define and not really expecting such value (There are several > >> projects supporting more than one ffmpeg release and "MAJOR <= xx" > >> checks are commonplace). > > > > IMO users who don't expect such a value shouldn't be linking against > > unstable API/ABI anyway. We could also set the major version to > > something really big, like 999. We'll have to change deprecation macros, > > but that should be straightforward. > > > >> Also, if we are going to code the instability period in some form into > >> the codebase, might as well make it so it starts with the first removal > >> commit, or immediately before it, so what you described above is no > >> longer a concern. > > > > I'd rather say the two concerns merge into one, but it's not going away. > > There's currently very little user indication that API/ABI are unstable > > for several months. > > How about making minor == 0 mean unstable? Some projects like GCC do it > like this, for example. Said version would not guarantee anything at all > and should not be linked against. Then once the period ends after the > major bump, it's bumped to 1, and the usual "new API, minor bump" rule > kicks in. > This also means that any API addition that takes place during the > unstable period doesn't get it's own version, and they will all strictly > speaking be introduced by minor 1. We'd have to watch this carefully, many developers don't pay attention to major bumps or instability periods and just bump minor anyway. We should also print a warning in configure that tells the user their build is unstable. Otherwise I'm ok with this. > As for your concern about first removing then bumping meaning we're > lying about the ABI, the first commit in the set could maybe rollback > minor to 0, then apply the removals, and finally the major bump in the > last commit. It will that way be considered unstable for the whole thing. Works for me.
On Wed, Jan 18, 2023 at 06:23:43PM -0300, James Almer wrote: > On 1/18/2023 4:28 PM, Anton Khirnov wrote: > > Quoting James Almer (2023-01-16 14:38:14) > > > It's been a while since the last bump, so it's time to do some cleaning and > > > remove deprecated APIs. This will also give us an "Open ABI season" in which we > > > can do breaking changes (like changing public struct offsets, public enum > > > values, adding fields to structs that have their size tied to the ABI, etc) for > > > a few weeks. > > > > Last time this open season lasted something like half a year and only > > ended when I arbitrarily said it did. > > > > So I'd suggest to decide right now how long will the instability period > > last (6 weeks should be enough for everybody) and write the end date at > > the top of doc/APIchanges. > > > > Another thing I'm not entirely happy about is versioning during the bump > > and instability. While the remove-then-bump approach does make bisection > > easier, it also creates commits that lie about their ABI version. > > Does it really matter? All the patches will be pushed at the same time, > meaning one git fetch will give you a stable state pre bump and the next > will be right after it. > I think it's a bit farfetched to expect someone to pick a random commit in > the middle of the bump and try to use the resulting compiled libraries with > some program that was linked to some earlier version libraries. > > > > > I wonder if we couldn't come up with a better soltion. One thing that > > comes to mind is setting the major version to 0 until the instability > > period ends. > > This could have several undesired effects, mainly for users looking at that > define and not really expecting such value (There are several projects > supporting more than one ffmpeg release and "MAJOR <= xx" checks are > commonplace). API/ABI is defined by major minor patchlevel these do have reasonable agreed upon meaning i think. I dont think code pushed to master should break the promise the verions make. If it breaks it, it should not be pushed. Not with VERY good reason, anything could have some rare exception if theres a very good reason for the expcetion ... A user or a script should always be able to checkout a version from master and its major:minor:patchlevel versions should work as one would expect I dont see why any exception is needed A new major API will start with a new major version and 0 in minor obviously now nothing at that time will depend on that major API version. And once some other libs or apps depend on the new major API they at the same time will require a minimum minor version and that minir version obviously will be after the instability period because you cant really depend on unstable API/ABI. So nothing would break from anything in that 0..X minor version range because nothing should depend on that and after X things are after the instability period. But we can still even in the instability period use the minor version for our own inter lib dependancies and handle that in a somewhat clean way by bumping minor when it is appropriate PS: iam not sure i fully understood the reason behind why versions should be set to "wrong" values during some period, so as always i might be missing something thx [...]
ons 2023-01-18 klockan 18:23 -0300 skrev James Almer: > On 1/18/2023 4:28 PM, Anton Khirnov wrote: > > Quoting James Almer (2023-01-16 14:38:14) > > > It's been a while since the last bump, so it's time to do some > > > cleaning and > > > remove deprecated APIs. This will also give us an "Open ABI > > > season" in which we > > > can do breaking changes (like changing public struct offsets, > > > public enum > > > values, adding fields to structs that have their size tied to the > > > ABI, etc) for > > > a few weeks. > > > > Last time this open season lasted something like half a year and > > only > > ended when I arbitrarily said it did. > > > > So I'd suggest to decide right now how long will the instability > > period > > last (6 weeks should be enough for everybody) and write the end > > date at > > the top of doc/APIchanges. > > > > Another thing I'm not entirely happy about is versioning during the > > bump > > and instability. While the remove-then-bump approach does make > > bisection > > easier, it also creates commits that lie about their ABI version. > > Does it really matter? All the patches will be pushed at the same > time, > meaning one git fetch will give you a stable state pre bump and the > next > will be right after it. > I think it's a bit farfetched to expect someone to pick a random > commit > in the middle of the bump and try to use the resulting compiled > libraries with some program that was linked to some earlier version > libraries. This is easily fixed by having a feature branch for the bumps and merging it with --no-ff. git bisect is clever enough to skip past such things /Tomas
On 1/18/23 14:28, Anton Khirnov wrote: > Quoting James Almer (2023-01-16 14:38:14) >> It's been a while since the last bump, so it's time to do some cleaning and >> remove deprecated APIs. This will also give us an "Open ABI season" in which we >> can do breaking changes (like changing public struct offsets, public enum >> values, adding fields to structs that have their size tied to the ABI, etc) for >> a few weeks. > > Last time this open season lasted something like half a year and only > ended when I arbitrarily said it did. > > So I'd suggest to decide right now how long will the instability period > last (6 weeks should be enough for everybody) and write the end date at > the top of doc/APIchanges. > > Another thing I'm not entirely happy about is versioning during the bump > and instability. While the remove-then-bump approach does make bisection > easier, it also creates commits that lie about their ABI version. > If the bump comes before the resulting removals, then wouldn't the removals strictly speaking exist inside the instability period as they immediately follow a version bump? This sounds like it keeps our promise. - Leo Izen
Quoting Michael Niedermayer (2023-01-20 03:05:09) > PS: iam not sure i fully understood the reason behind why versions should be > set to "wrong" values during some period, so as always i might be missing > something The reason is that after the major bump, the API and ABI are declared to be unstable for some period, so people can freely - break ABI, e.g. by reordering struct members - modify API added during the instability period in an arbitrary way without a new major bump for every such change, that would be normally required. My concern is that the instability period is quite long and there is very little indication for our users that they cannot depend on the ABI/API being stable. So I'm proposing to introduce some mechanism to make this more visible for our callers. Alternatively, we could just not have an instability period at all.
Quoting Leo Izen (2023-01-20 22:23:23) > On 1/18/23 14:28, Anton Khirnov wrote: > > Quoting James Almer (2023-01-16 14:38:14) > >> It's been a while since the last bump, so it's time to do some cleaning and > >> remove deprecated APIs. This will also give us an "Open ABI season" in which we > >> can do breaking changes (like changing public struct offsets, public enum > >> values, adding fields to structs that have their size tied to the ABI, etc) for > >> a few weeks. > > > > Last time this open season lasted something like half a year and only > > ended when I arbitrarily said it did. > > > > So I'd suggest to decide right now how long will the instability period > > last (6 weeks should be enough for everybody) and write the end date at > > the top of doc/APIchanges. > > > > Another thing I'm not entirely happy about is versioning during the bump > > and instability. While the remove-then-bump approach does make bisection > > easier, it also creates commits that lie about their ABI version. > > > > If the bump comes before the resulting removals, then wouldn't the > removals strictly speaking exist inside the instability period as they > immediately follow a version bump? This sounds like it keeps our promise. With the way deprecation guards are typically structured, the bump itself disables all deprecated code atomically. The removals then just drop dead code. So even without an instability period this would work "correctly" and that's how I used to do it. However some people dislike so much code being disabled in a single commit, since that is harder to bisect if the bump introduces any issues..
On 21 Jan 2023, at 17:51, Anton Khirnov wrote: > Quoting Michael Niedermayer (2023-01-20 03:05:09) >> PS: iam not sure i fully understood the reason behind why versions should be >> set to "wrong" values during some period, so as always i might be missing >> something > > The reason is that after the major bump, the API and ABI are declared to > be unstable for some period, so people can freely > - break ABI, e.g. by reordering struct members > - modify API added during the instability period in an arbitrary way > without a new major bump for every such change, that would be normally > required. > > My concern is that the instability period is quite long and there is > very little indication for our users that they cannot depend on the > ABI/API being stable. So I'm proposing to introduce some mechanism to > make this more visible for our callers. I agree that a better way to know when I have an "unstable" version of ffmpeg would be great. Even as someone loosely following ffmpeg dev it is not clear to me when instability period ends and if we are currently in it or not. (I mean, I was lucky enough to notice this email now this time, but that was pure luck…) > > Alternatively, we could just not have an instability period at all. > Not having any instability period at all seems like a bad idea. > -- > Anton Khirnov > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
On Sat, Jan 21, 2023 at 8:33 PM Marvin Scholz <epirat07@gmail.com> wrote: > > > > Alternatively, we could just not have an instability period at all. > > > > Not having any instability period at all seems like a bad idea. > Actually that sounds like the best idea. You would just have to prepare the bump in a branch and all unstable changes ready to merge in an instant. Miss it? Tough. Having months long periods so people can get their stuff sorted is way too long. Ideally it should be prepared ahead of time and only a "soft instability" period of maybe two weeks reserved for bug fixes (don't want to sit on issues for ever), rather then big changes or new features. - Hendrik
On 21 Jan 2023, at 21:17, Hendrik Leppkes wrote: > On Sat, Jan 21, 2023 at 8:33 PM Marvin Scholz <epirat07@gmail.com> wrote: >>> >>> Alternatively, we could just not have an instability period at all. >>> >> >> Not having any instability period at all seems like a bad idea. >> > > Actually that sounds like the best idea. You would just have to > prepare the bump in a branch and all unstable changes ready to merge > in an instant. > Miss it? Tough. Having months long periods so people can get their > stuff sorted is way too long. Ideally it should be prepared ahead of > time and only a "soft instability" period of maybe two weeks reserved > for bug fixes (don't want to sit on issues for ever), rather then big > changes or new features. > How would it work? If I now make a branch with a breaking change, where would I put it and how would I get it merged together with the other breaking changes? Or do you mean that there should be a public devel branch where API/ABI breaking patches can be proposed for that will eventually be merged into master at a defined point in time together with major bump? > - Hendrik > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
On Sat, Jan 21, 2023 at 05:51:34PM +0100, Anton Khirnov wrote: > Quoting Michael Niedermayer (2023-01-20 03:05:09) > > PS: iam not sure i fully understood the reason behind why versions should be > > set to "wrong" values during some period, so as always i might be missing > > something > > The reason is that after the major bump, the API and ABI are declared to > be unstable for some period, so people can freely > - break ABI, e.g. by reordering struct members > - modify API added during the instability period in an arbitrary way > without a new major bump for every such change, that would be normally > required. > > My concern is that the instability period is quite long and there is > very little indication for our users that they cannot depend on the > ABI/API being stable. So I'm proposing to introduce some mechanism to > make this more visible for our callers. > > Alternatively, we could just not have an instability period at all. Does anyone plan to use the next bumps instability period for anything ? If so, i assume theres a good reason why it cannot be done without such period easily? If theres noone -> easy solution, we need no instability period ATM. If theres someone, i would ask that someone how long it needs to be and write that down in APIchanges. Maybe as in "API is unstable becuase of X until 2033-11-11 a new #define LIBAVCODEC_UNSTABLE could be added but izt feels a bit overengeneered. This whole thing is more a exception, isnt it? thx [...]
On Sat, 21 Jan 2023, Michael Niedermayer wrote: > On Sat, Jan 21, 2023 at 05:51:34PM +0100, Anton Khirnov wrote: >> Quoting Michael Niedermayer (2023-01-20 03:05:09) >>> PS: iam not sure i fully understood the reason behind why versions should be >>> set to "wrong" values during some period, so as always i might be missing >>> something >> >> The reason is that after the major bump, the API and ABI are declared to >> be unstable for some period, so people can freely >> - break ABI, e.g. by reordering struct members >> - modify API added during the instability period in an arbitrary way >> without a new major bump for every such change, that would be normally >> required. >> >> My concern is that the instability period is quite long and there is >> very little indication for our users that they cannot depend on the >> ABI/API being stable. So I'm proposing to introduce some mechanism to >> make this more visible for our callers. >> >> Alternatively, we could just not have an instability period at all. > > Does anyone plan to use the next bumps instability period for anything ? > If so, i assume theres a good reason why it cannot be done without such > period easily? AVCodecContext->frame_number should be changed to int64_t. I guess you could do something similar which was done for buffer_size_t, but that seems like a lot of extra work and ifdefry for questionable benefit. Regards, Marton > > If theres noone -> easy solution, we need no instability period ATM. > If theres someone, i would ask that someone how long it needs to be > and write that down in APIchanges. Maybe as in "API is unstable becuase > of X until 2033-11-11 > > a new #define LIBAVCODEC_UNSTABLE could be added but izt feels a bit > overengeneered. This whole thing is more a exception, isnt it? > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > While the State exists there can be no freedom; when there is freedom there > will be no State. -- Vladimir Lenin >
On 21 Jan 2023, at 22:36, Michael Niedermayer wrote: > On Sat, Jan 21, 2023 at 05:51:34PM +0100, Anton Khirnov wrote: >> Quoting Michael Niedermayer (2023-01-20 03:05:09) >>> PS: iam not sure i fully understood the reason behind why versions should be >>> set to "wrong" values during some period, so as always i might be missing >>> something >> >> The reason is that after the major bump, the API and ABI are declared to >> be unstable for some period, so people can freely >> - break ABI, e.g. by reordering struct members >> - modify API added during the instability period in an arbitrary way >> without a new major bump for every such change, that would be normally >> required. >> >> My concern is that the instability period is quite long and there is >> very little indication for our users that they cannot depend on the >> ABI/API being stable. So I'm proposing to introduce some mechanism to >> make this more visible for our callers. >> >> Alternatively, we could just not have an instability period at all. > > Does anyone plan to use the next bumps instability period for anything ? > If so, i assume theres a good reason why it cannot be done without such > period easily? > > If theres noone -> easy solution, we need no instability period ATM. > If theres someone, i would ask that someone how long it needs to be > and write that down in APIchanges. Maybe as in "API is unstable becuase > of X until 2033-11-11 > I would like to make av_dict_get return a const AVDictionaryEntry, just like av_dict_iterate already does. > a new #define LIBAVCODEC_UNSTABLE could be added but izt feels a bit > overengeneered. This whole thing is more a exception, isnt it? > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > While the State exists there can be no freedom; when there is freedom there > will be no State. -- Vladimir Lenin > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
On Sat, Jan 21, 2023 at 10:30 PM Marvin Scholz <epirat07@gmail.com> wrote: > > Or do you mean that there should be a public devel branch where API/ABI > breaking patches can be proposed for that will eventually be merged into > master at a defined point in time together with major bump? > Yes, I'm talking about one centrally managed branch that contributors can merge their breaking changes to, and we can test it all in one piece, and then when the time comes, that one branch would get merged into master. - Hendrik
On Sat, Jan 21, 2023 at 11:00:52PM +0100, Marton Balint wrote: > > > On Sat, 21 Jan 2023, Michael Niedermayer wrote: > > > On Sat, Jan 21, 2023 at 05:51:34PM +0100, Anton Khirnov wrote: > > > Quoting Michael Niedermayer (2023-01-20 03:05:09) > > > > PS: iam not sure i fully understood the reason behind why versions should be > > > > set to "wrong" values during some period, so as always i might be missing > > > > something > > > > > > The reason is that after the major bump, the API and ABI are declared to > > > be unstable for some period, so people can freely > > > - break ABI, e.g. by reordering struct members > > > - modify API added during the instability period in an arbitrary way > > > without a new major bump for every such change, that would be normally > > > required. > > > > > > My concern is that the instability period is quite long and there is > > > very little indication for our users that they cannot depend on the > > > ABI/API being stable. So I'm proposing to introduce some mechanism to > > > make this more visible for our callers. > > > > > > Alternatively, we could just not have an instability period at all. > > > > Does anyone plan to use the next bumps instability period for anything ? > > If so, i assume theres a good reason why it cannot be done without such > > period easily? > > AVCodecContext->frame_number should be changed to int64_t. I guess you could Is there a patchset that does that already ? Iam asking as i think starting work on this after the bump would be the wrong approuch Also how long of a instability period do you expect this would need ? Or maybe the question is who would work on this and have it toward the top of their todo list. thx [...]
Quoting Marton Balint (2023-01-21 23:00:52) > > > On Sat, 21 Jan 2023, Michael Niedermayer wrote: > > > On Sat, Jan 21, 2023 at 05:51:34PM +0100, Anton Khirnov wrote: > >> Quoting Michael Niedermayer (2023-01-20 03:05:09) > >>> PS: iam not sure i fully understood the reason behind why versions should be > >>> set to "wrong" values during some period, so as always i might be missing > >>> something > >> > >> The reason is that after the major bump, the API and ABI are declared to > >> be unstable for some period, so people can freely > >> - break ABI, e.g. by reordering struct members > >> - modify API added during the instability period in an arbitrary way > >> without a new major bump for every such change, that would be normally > >> required. > >> > >> My concern is that the instability period is quite long and there is > >> very little indication for our users that they cannot depend on the > >> ABI/API being stable. So I'm proposing to introduce some mechanism to > >> make this more visible for our callers. > >> > >> Alternatively, we could just not have an instability period at all. > > > > Does anyone plan to use the next bumps instability period for anything ? > > If so, i assume theres a good reason why it cannot be done without such > > period easily? > > AVCodecContext->frame_number should be changed to int64_t. I guess you > could do something similar which was done for buffer_size_t, but that > seems like a lot of extra work and ifdefry for questionable benefit. Not breaking callers seems like a very solid benefit to me.
On Mon, 23 Jan 2023, Anton Khirnov wrote: > Quoting Marton Balint (2023-01-21 23:00:52) >> >> >> On Sat, 21 Jan 2023, Michael Niedermayer wrote: >> >>> On Sat, Jan 21, 2023 at 05:51:34PM +0100, Anton Khirnov wrote: >>>> Quoting Michael Niedermayer (2023-01-20 03:05:09) >>>>> PS: iam not sure i fully understood the reason behind why versions should be >>>>> set to "wrong" values during some period, so as always i might be missing >>>>> something >>>> >>>> The reason is that after the major bump, the API and ABI are declared to >>>> be unstable for some period, so people can freely >>>> - break ABI, e.g. by reordering struct members >>>> - modify API added during the instability period in an arbitrary way >>>> without a new major bump for every such change, that would be normally >>>> required. >>>> >>>> My concern is that the instability period is quite long and there is >>>> very little indication for our users that they cannot depend on the >>>> ABI/API being stable. So I'm proposing to introduce some mechanism to >>>> make this more visible for our callers. >>>> >>>> Alternatively, we could just not have an instability period at all. >>> >>> Does anyone plan to use the next bumps instability period for anything ? >>> If so, i assume theres a good reason why it cannot be done without such >>> period easily? >> >> AVCodecContext->frame_number should be changed to int64_t. I guess you >> could do something similar which was done for buffer_size_t, but that >> seems like a lot of extra work and ifdefry for questionable benefit. > > Not breaking callers seems like a very solid benefit to me. I am not sure if I see your point, during unstable, you can break callers, and I planned to do the change during unstable. Regards, Marton
Quoting Marton Balint (2023-01-23 23:41:11) > On Mon, 23 Jan 2023, Anton Khirnov wrote: > > Quoting Marton Balint (2023-01-21 23:00:52) > >> AVCodecContext->frame_number should be changed to int64_t. I guess you > >> could do something similar which was done for buffer_size_t, but that > >> seems like a lot of extra work and ifdefry for questionable benefit. > > > > Not breaking callers seems like a very solid benefit to me. > > I am not sure if I see your point, during unstable, you can break callers, > and I planned to do the change during unstable. My understanding of this instability period is that it's mainly for ABI changes like reordering struct fields and such, you're still not allowed to arbitrarily break random APIs. The entire point of having deprecation periods is that callers can prepare in advance and never actually be broken.
On Mon, 23 Jan 2023, Anton Khirnov wrote: > Quoting Marton Balint (2023-01-23 23:41:11) >> On Mon, 23 Jan 2023, Anton Khirnov wrote: >>> Quoting Marton Balint (2023-01-21 23:00:52) >>>> AVCodecContext->frame_number should be changed to int64_t. I guess you >>>> could do something similar which was done for buffer_size_t, but that >>>> seems like a lot of extra work and ifdefry for questionable benefit. >>> >>> Not breaking callers seems like a very solid benefit to me. >> >> I am not sure if I see your point, during unstable, you can break callers, >> and I planned to do the change during unstable. > > My understanding of this instability period is that it's mainly for ABI > changes like reordering struct fields and such, you're still not allowed > to arbitrarily break random APIs. The entire point of having deprecation > periods is that callers can prepare in advance and never actually be > broken. If some fields or API is deprecated, then yes, it makes sense. But if no deprecation / replacement API is provided, then how will anybody prepare? For type changes, fields are usually not deprecated. Ifdefs are only used to prepare the changes for the next API bump. For example, buffer_size_t was in the codebase for 2 months only. It is not that big of a deal to make a patch if #ifdefs, I just really don't see the benefit. An actual problem however, is that printf() like functions expect type specifiers, and unlike buffer sizes, there is a good chance the users sometimes print AVCodecContext->frame_number or AVFrame->xxx_picture_number, which will become undefined behaviour. And yes, the compiler will usually warn, but still, type changes can cause silent breakage. But using #define API guards will not fix this, whenever you change the type, code will get broken, I am not sure if anything can be done about it. Regards, Marton > > -- > Anton Khirnov > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". >
On Tue, Jan 24, 2023 at 12:22:52AM +0100, Marton Balint wrote: > > > On Mon, 23 Jan 2023, Anton Khirnov wrote: > > > Quoting Marton Balint (2023-01-23 23:41:11) > > > On Mon, 23 Jan 2023, Anton Khirnov wrote: > > > > Quoting Marton Balint (2023-01-21 23:00:52) > > > > > AVCodecContext->frame_number should be changed to int64_t. I guess you > > > > > could do something similar which was done for buffer_size_t, but that > > > > > seems like a lot of extra work and ifdefry for questionable benefit. > > > > > > > > Not breaking callers seems like a very solid benefit to me. > > > > > > I am not sure if I see your point, during unstable, you can break callers, > > > and I planned to do the change during unstable. > > > > My understanding of this instability period is that it's mainly for ABI > > changes like reordering struct fields and such, you're still not allowed > > to arbitrarily break random APIs. The entire point of having deprecation > > periods is that callers can prepare in advance and never actually be > > broken. > > If some fields or API is deprecated, then yes, it makes sense. But if no > deprecation / replacement API is provided, then how will anybody prepare? > For type changes, fields are usually not deprecated. Ifdefs are only used to > prepare the changes for the next API bump. For example, buffer_size_t was in > the codebase for 2 months only. > > It is not that big of a deal to make a patch if #ifdefs, I just really don't > see the benefit. > > An actual problem however, is that printf() like functions expect type > specifiers, and unlike buffer sizes, there is a good chance the users > sometimes print AVCodecContext->frame_number or AVFrame->xxx_picture_number, > which will become undefined behaviour. And yes, the compiler will usually > warn, but still, type changes can cause silent breakage. But using #define > API guards will not fix this, whenever you change the type, code will get > broken, I am not sure if anything can be done about it. if you want to avoid this then, new type, new identifer [...]
On Tue, 24 Jan 2023, Michael Niedermayer wrote: > On Tue, Jan 24, 2023 at 12:22:52AM +0100, Marton Balint wrote: >> >> >> On Mon, 23 Jan 2023, Anton Khirnov wrote: >> >>> Quoting Marton Balint (2023-01-23 23:41:11) >>>> On Mon, 23 Jan 2023, Anton Khirnov wrote: >>>>> Quoting Marton Balint (2023-01-21 23:00:52) >>>>>> AVCodecContext->frame_number should be changed to int64_t. I guess you >>>>>> could do something similar which was done for buffer_size_t, but that >>>>>> seems like a lot of extra work and ifdefry for questionable benefit. >>>>> >>>>> Not breaking callers seems like a very solid benefit to me. >>>> >>>> I am not sure if I see your point, during unstable, you can break callers, >>>> and I planned to do the change during unstable. >>> >>> My understanding of this instability period is that it's mainly for ABI >>> changes like reordering struct fields and such, you're still not allowed >>> to arbitrarily break random APIs. The entire point of having deprecation >>> periods is that callers can prepare in advance and never actually be >>> broken. >> >> If some fields or API is deprecated, then yes, it makes sense. But if no >> deprecation / replacement API is provided, then how will anybody prepare? >> For type changes, fields are usually not deprecated. Ifdefs are only used to >> prepare the changes for the next API bump. For example, buffer_size_t was in >> the codebase for 2 months only. >> >> It is not that big of a deal to make a patch if #ifdefs, I just really don't >> see the benefit. >> >> An actual problem however, is that printf() like functions expect type >> specifiers, and unlike buffer sizes, there is a good chance the users >> sometimes print AVCodecContext->frame_number or AVFrame->xxx_picture_number, >> which will become undefined behaviour. And yes, the compiler will usually >> warn, but still, type changes can cause silent breakage. But using #define >> API guards will not fix this, whenever you change the type, code will get >> broken, I am not sure if anything can be done about it. > > if you want to avoid this then, new type, new identifer Sure, but do we want AVFrame->coded_picture_number64, AVFrame->display_picture_number64 and AVCodecContext->frame_number64? Regards, Marton
Quoting Marton Balint (2023-01-24 01:06:46) > On Tue, 24 Jan 2023, Michael Niedermayer wrote: > > On Tue, Jan 24, 2023 at 12:22:52AM +0100, Marton Balint wrote: > >> On Mon, 23 Jan 2023, Anton Khirnov wrote: > >>> Quoting Marton Balint (2023-01-23 23:41:11) > >>>> On Mon, 23 Jan 2023, Anton Khirnov wrote: > >>>>> Not breaking callers seems like a very solid benefit to me. > >>>> > >>>> I am not sure if I see your point, during unstable, you can break callers, > >>>> and I planned to do the change during unstable. > >>> > >>> My understanding of this instability period is that it's mainly for ABI > >>> changes like reordering struct fields and such, you're still not allowed > >>> to arbitrarily break random APIs. The entire point of having deprecation > >>> periods is that callers can prepare in advance and never actually be > >>> broken. > >> > >> If some fields or API is deprecated, then yes, it makes sense. But if no > >> deprecation / replacement API is provided, then how will anybody prepare? > >> For type changes, fields are usually not deprecated. Ifdefs are only used to > >> prepare the changes for the next API bump. For example, buffer_size_t was in > >> the codebase for 2 months only. > >> > >> It is not that big of a deal to make a patch if #ifdefs, I just really don't > >> see the benefit. > >> > >> An actual problem however, is that printf() like functions expect type > >> specifiers, and unlike buffer sizes, there is a good chance the users > >> sometimes print AVCodecContext->frame_number or AVFrame->xxx_picture_number, > >> which will become undefined behaviour. And yes, the compiler will usually > >> warn, but still, type changes can cause silent breakage. But using #define > >> API guards will not fix this, whenever you change the type, code will get > >> broken, I am not sure if anything can be done about it. > > if you want to avoid this then, new type, new identifer > Sure, but do we want AVFrame->coded_picture_number64, > AVFrame->display_picture_number64 Are these even useful for anything? The don't seem like they belong in AVFrame.
So to summarize the discussion so far:
* nobody is strongly arguing for an instability period after the bump,
and there are good reasons against it, therefore we should NOT have
one
* the bump can be done either as bump-then-remove or remove-then-bump
* there are advantages and disadvantages for both of those, nobody
expressed a strong preference for either, so you can keep this as
is
Please correct me if I misunderstood or missed something, or somebody
has a new opinion.
On Tue, 24 Jan 2023, Anton Khirnov wrote: > Quoting Marton Balint (2023-01-24 01:06:46) >> On Tue, 24 Jan 2023, Michael Niedermayer wrote: >>> On Tue, Jan 24, 2023 at 12:22:52AM +0100, Marton Balint wrote: >>>> On Mon, 23 Jan 2023, Anton Khirnov wrote: >>>>> Quoting Marton Balint (2023-01-23 23:41:11) >>>>>> On Mon, 23 Jan 2023, Anton Khirnov wrote: >>>>>>> Not breaking callers seems like a very solid benefit to me. >>>>>> >>>>>> I am not sure if I see your point, during unstable, you can break callers, >>>>>> and I planned to do the change during unstable. >>>>> >>>>> My understanding of this instability period is that it's mainly for ABI >>>>> changes like reordering struct fields and such, you're still not allowed >>>>> to arbitrarily break random APIs. The entire point of having deprecation >>>>> periods is that callers can prepare in advance and never actually be >>>>> broken. >>>> >>>> If some fields or API is deprecated, then yes, it makes sense. But if no >>>> deprecation / replacement API is provided, then how will anybody prepare? >>>> For type changes, fields are usually not deprecated. Ifdefs are only used to >>>> prepare the changes for the next API bump. For example, buffer_size_t was in >>>> the codebase for 2 months only. >>>> >>>> It is not that big of a deal to make a patch if #ifdefs, I just really don't >>>> see the benefit. >>>> >>>> An actual problem however, is that printf() like functions expect type >>>> specifiers, and unlike buffer sizes, there is a good chance the users >>>> sometimes print AVCodecContext->frame_number or AVFrame->xxx_picture_number, >>>> which will become undefined behaviour. And yes, the compiler will usually >>>> warn, but still, type changes can cause silent breakage. But using #define >>>> API guards will not fix this, whenever you change the type, code will get >>>> broken, I am not sure if anything can be done about it. >>> if you want to avoid this then, new type, new identifer >> Sure, but do we want AVFrame->coded_picture_number64, >> AVFrame->display_picture_number64 > > Are these even useful for anything? The don't seem like they belong in > AVFrame. It might have some users as some decoders (Dirac or AVS3-P2) set it based on bitstream values. Plus mpegvideoenc is also using it for something... Regards, Marton
On 1/24/2023 12:45 PM, Anton Khirnov wrote: > So to summarize the discussion so far: > > * nobody is strongly arguing for an instability period after the bump, > and there are good reasons against it, therefore we should NOT have > one > > * the bump can be done either as bump-then-remove or remove-then-bump > * there are advantages and disadvantages for both of those, nobody > expressed a strong preference for either, so you can keep this as > is > > Please correct me if I misunderstood or missed something, or somebody > has a new opinion. Since the instability period doesn't seem popular, if anyone has some patches for ABI changes (enum value or field offset changes, removing avpriv_ functions we forgot about, etc), then please send them asap so i can push them all at the same time. Otherwise, lets just do what we always did but limit it to one week, after which too bad.
On Wed, 25 Jan 2023, James Almer wrote: > On 1/24/2023 12:45 PM, Anton Khirnov wrote: >> So to summarize the discussion so far: >> >> * nobody is strongly arguing for an instability period after the bump, >> and there are good reasons against it, therefore we should NOT have >> one >> >> * the bump can be done either as bump-then-remove or remove-then-bump >> * there are advantages and disadvantages for both of those, nobody >> expressed a strong preference for either, so you can keep this as >> is >> >> Please correct me if I misunderstood or missed something, or somebody >> has a new opinion. > > Since the instability period doesn't seem popular, if anyone has some patches > for ABI changes (enum value or field offset changes, removing avpriv_ > functions we forgot about, etc), then please send them asap so i can push > them all at the same time. Ok, I can send the frame number changes tomorrow. When do you plan to do the actual bump? I assumed the last 5.x release should be branched first. Regards, Marton
On Wed, 25 Jan 2023, at 21:08, Marton Balint wrote: > On Wed, 25 Jan 2023, James Almer wrote: > >> On 1/24/2023 12:45 PM, Anton Khirnov wrote: >>> So to summarize the discussion so far: >>> >>> * nobody is strongly arguing for an instability period after the bump, >>> and there are good reasons against it, therefore we should NOT have >>> one >>> >>> * the bump can be done either as bump-then-remove or remove-then-bump >>> * there are advantages and disadvantages for both of those, nobody >>> expressed a strong preference for either, so you can keep this as >>> is >>> >>> Please correct me if I misunderstood or missed something, or somebody >>> has a new opinion. >> >> Since the instability period doesn't seem popular, if anyone has some patches >> for ABI changes (enum value or field offset changes, removing avpriv_ >> functions we forgot about, etc), then please send them asap so i can push >> them all at the same time. > > Ok, I can send the frame number changes tomorrow. When do you plan to do > the actual bump? I assumed the last 5.x release should be branched first. Why? 5.1 was already branched out. I would Bump and prepare 6.0 just after, no?
On Wed, 25 Jan 2023, Jean-Baptiste Kempf wrote: > On Wed, 25 Jan 2023, at 21:08, Marton Balint wrote: >> On Wed, 25 Jan 2023, James Almer wrote: >> >>> On 1/24/2023 12:45 PM, Anton Khirnov wrote: >>>> So to summarize the discussion so far: >>>> >>>> * nobody is strongly arguing for an instability period after the bump, >>>> and there are good reasons against it, therefore we should NOT have >>>> one >>>> >>>> * the bump can be done either as bump-then-remove or remove-then-bump >>>> * there are advantages and disadvantages for both of those, nobody >>>> expressed a strong preference for either, so you can keep this as >>>> is >>>> >>>> Please correct me if I misunderstood or missed something, or somebody >>>> has a new opinion. >>> >>> Since the instability period doesn't seem popular, if anyone has some patches >>> for ABI changes (enum value or field offset changes, removing avpriv_ >>> functions we forgot about, etc), then please send them asap so i can push >>> them all at the same time. >> >> Ok, I can send the frame number changes tomorrow. When do you plan to do >> the actual bump? I assumed the last 5.x release should be branched first. > > Why? 5.1 was already branched out. And is missing 6 months of development. IMHO it is friendly to users/packagers to have a release which have the latest features and API/ABI compatible with older releases. Distros or third party packagers can provide upgrades without breaking dependant apps. We followed the same path for the last major bump. Also I find it better to let things cool down a bit before we do a 6.0 release with the new major versions, even if the "unstable" period is 1 week only or less. Regards, Marton
On Wed, 25 Jan 2023, at 22:03, Marton Balint wrote: > On Wed, 25 Jan 2023, Jean-Baptiste Kempf wrote: > >> On Wed, 25 Jan 2023, at 21:08, Marton Balint wrote: >>> On Wed, 25 Jan 2023, James Almer wrote: >>> >>>> On 1/24/2023 12:45 PM, Anton Khirnov wrote: >>>>> So to summarize the discussion so far: >>>>> >>>>> * nobody is strongly arguing for an instability period after the bump, >>>>> and there are good reasons against it, therefore we should NOT have >>>>> one >>>>> >>>>> * the bump can be done either as bump-then-remove or remove-then-bump >>>>> * there are advantages and disadvantages for both of those, nobody >>>>> expressed a strong preference for either, so you can keep this as >>>>> is >>>>> >>>>> Please correct me if I misunderstood or missed something, or somebody >>>>> has a new opinion. >>>> >>>> Since the instability period doesn't seem popular, if anyone has some patches >>>> for ABI changes (enum value or field offset changes, removing avpriv_ >>>> functions we forgot about, etc), then please send them asap so i can push >>>> them all at the same time. >>> >>> Ok, I can send the frame number changes tomorrow. When do you plan to do >>> the actual bump? I assumed the last 5.x release should be branched first. >> >> Why? 5.1 was already branched out. > > And is missing 6 months of development. So you want us to release both 6.0 and 5.2 at the same time? I don't get it.
On 1/25/23, Jean-Baptiste Kempf <jb@videolan.org> wrote: > On Wed, 25 Jan 2023, at 22:03, Marton Balint wrote: >> On Wed, 25 Jan 2023, Jean-Baptiste Kempf wrote: >> >>> On Wed, 25 Jan 2023, at 21:08, Marton Balint wrote: >>>> On Wed, 25 Jan 2023, James Almer wrote: >>>> >>>>> On 1/24/2023 12:45 PM, Anton Khirnov wrote: >>>>>> So to summarize the discussion so far: >>>>>> >>>>>> * nobody is strongly arguing for an instability period after the >>>>>> bump, >>>>>> and there are good reasons against it, therefore we should NOT >>>>>> have >>>>>> one >>>>>> >>>>>> * the bump can be done either as bump-then-remove or >>>>>> remove-then-bump >>>>>> * there are advantages and disadvantages for both of those, >>>>>> nobody >>>>>> expressed a strong preference for either, so you can keep this >>>>>> as >>>>>> is >>>>>> >>>>>> Please correct me if I misunderstood or missed something, or >>>>>> somebody >>>>>> has a new opinion. >>>>> >>>>> Since the instability period doesn't seem popular, if anyone has some >>>>> patches >>>>> for ABI changes (enum value or field offset changes, removing avpriv_ >>>>> functions we forgot about, etc), then please send them asap so i can >>>>> push >>>>> them all at the same time. >>>> >>>> Ok, I can send the frame number changes tomorrow. When do you plan to >>>> do >>>> the actual bump? I assumed the last 5.x release should be branched >>>> first. >>> >>> Why? 5.1 was already branched out. >> >> And is missing 6 months of development. > > So you want us to release both 6.0 and 5.2 at the same time? > I don't get it. So user do not need to immediately update code that uses old API to get new fancy features. > > -- > Jean-Baptiste Kempf - President > +33 672 704 734 > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". >
On Wed, 25 Jan 2023, at 22:20, Paul B Mahol wrote: > On 1/25/23, Jean-Baptiste Kempf <jb@videolan.org> wrote: >> On Wed, 25 Jan 2023, at 22:03, Marton Balint wrote: >>> On Wed, 25 Jan 2023, Jean-Baptiste Kempf wrote: >>> >>>> On Wed, 25 Jan 2023, at 21:08, Marton Balint wrote: >>>>> On Wed, 25 Jan 2023, James Almer wrote: >>>>> >>>>>> On 1/24/2023 12:45 PM, Anton Khirnov wrote: >>>>>>> So to summarize the discussion so far: >>>>>>> >>>>>>> * nobody is strongly arguing for an instability period after the >>>>>>> bump, >>>>>>> and there are good reasons against it, therefore we should NOT >>>>>>> have >>>>>>> one >>>>>>> >>>>>>> * the bump can be done either as bump-then-remove or >>>>>>> remove-then-bump >>>>>>> * there are advantages and disadvantages for both of those, >>>>>>> nobody >>>>>>> expressed a strong preference for either, so you can keep this >>>>>>> as >>>>>>> is >>>>>>> >>>>>>> Please correct me if I misunderstood or missed something, or >>>>>>> somebody >>>>>>> has a new opinion. >>>>>> >>>>>> Since the instability period doesn't seem popular, if anyone has some >>>>>> patches >>>>>> for ABI changes (enum value or field offset changes, removing avpriv_ >>>>>> functions we forgot about, etc), then please send them asap so i can >>>>>> push >>>>>> them all at the same time. >>>>> >>>>> Ok, I can send the frame number changes tomorrow. When do you plan to >>>>> do >>>>> the actual bump? I assumed the last 5.x release should be branched >>>>> first. >>>> >>>> Why? 5.1 was already branched out. >>> >>> And is missing 6 months of development. >> >> So you want us to release both 6.0 and 5.2 at the same time? >> I don't get it. > > So user do not need to immediately update code that uses old API to > get new fancy features. And when do you stop doing this? Also, as 5.1 is LTS, is 5.2 LTS too?
On 1/25/23, Jean-Baptiste Kempf <jb@videolan.org> wrote: > > > On Wed, 25 Jan 2023, at 22:20, Paul B Mahol wrote: >> On 1/25/23, Jean-Baptiste Kempf <jb@videolan.org> wrote: >>> On Wed, 25 Jan 2023, at 22:03, Marton Balint wrote: >>>> On Wed, 25 Jan 2023, Jean-Baptiste Kempf wrote: >>>> >>>>> On Wed, 25 Jan 2023, at 21:08, Marton Balint wrote: >>>>>> On Wed, 25 Jan 2023, James Almer wrote: >>>>>> >>>>>>> On 1/24/2023 12:45 PM, Anton Khirnov wrote: >>>>>>>> So to summarize the discussion so far: >>>>>>>> >>>>>>>> * nobody is strongly arguing for an instability period after the >>>>>>>> bump, >>>>>>>> and there are good reasons against it, therefore we should NOT >>>>>>>> have >>>>>>>> one >>>>>>>> >>>>>>>> * the bump can be done either as bump-then-remove or >>>>>>>> remove-then-bump >>>>>>>> * there are advantages and disadvantages for both of those, >>>>>>>> nobody >>>>>>>> expressed a strong preference for either, so you can keep >>>>>>>> this >>>>>>>> as >>>>>>>> is >>>>>>>> >>>>>>>> Please correct me if I misunderstood or missed something, or >>>>>>>> somebody >>>>>>>> has a new opinion. >>>>>>> >>>>>>> Since the instability period doesn't seem popular, if anyone has >>>>>>> some >>>>>>> patches >>>>>>> for ABI changes (enum value or field offset changes, removing >>>>>>> avpriv_ >>>>>>> functions we forgot about, etc), then please send them asap so i can >>>>>>> push >>>>>>> them all at the same time. >>>>>> >>>>>> Ok, I can send the frame number changes tomorrow. When do you plan to >>>>>> do >>>>>> the actual bump? I assumed the last 5.x release should be branched >>>>>> first. >>>>> >>>>> Why? 5.1 was already branched out. >>>> >>>> And is missing 6 months of development. >>> >>> So you want us to release both 6.0 and 5.2 at the same time? >>> I don't get it. >> >> So user do not need to immediately update code that uses old API to >> get new fancy features. > > And when do you stop doing this? After 6.0 tagged. > Also, as 5.1 is LTS, is 5.2 LTS too? > No, its not. > -- > Jean-Baptiste Kempf - President > +33 672 704 734 > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". >
On Wed, 25 Jan 2023, at 22:29, Paul B Mahol wrote: > On 1/25/23, Jean-Baptiste Kempf <jb@videolan.org> wrote: >> >> >> On Wed, 25 Jan 2023, at 22:20, Paul B Mahol wrote: >>> On 1/25/23, Jean-Baptiste Kempf <jb@videolan.org> wrote: >>>> On Wed, 25 Jan 2023, at 22:03, Marton Balint wrote: >>>>> On Wed, 25 Jan 2023, Jean-Baptiste Kempf wrote: >>>>> >>>>>> On Wed, 25 Jan 2023, at 21:08, Marton Balint wrote: >>>>>>> On Wed, 25 Jan 2023, James Almer wrote: >>>>>>> >>>>>>>> On 1/24/2023 12:45 PM, Anton Khirnov wrote: >>>>>>>>> So to summarize the discussion so far: >>>>>>>>> >>>>>>>>> * nobody is strongly arguing for an instability period after the >>>>>>>>> bump, >>>>>>>>> and there are good reasons against it, therefore we should NOT >>>>>>>>> have >>>>>>>>> one >>>>>>>>> >>>>>>>>> * the bump can be done either as bump-then-remove or >>>>>>>>> remove-then-bump >>>>>>>>> * there are advantages and disadvantages for both of those, >>>>>>>>> nobody >>>>>>>>> expressed a strong preference for either, so you can keep >>>>>>>>> this >>>>>>>>> as >>>>>>>>> is >>>>>>>>> >>>>>>>>> Please correct me if I misunderstood or missed something, or >>>>>>>>> somebody >>>>>>>>> has a new opinion. >>>>>>>> >>>>>>>> Since the instability period doesn't seem popular, if anyone has >>>>>>>> some >>>>>>>> patches >>>>>>>> for ABI changes (enum value or field offset changes, removing >>>>>>>> avpriv_ >>>>>>>> functions we forgot about, etc), then please send them asap so i can >>>>>>>> push >>>>>>>> them all at the same time. >>>>>>> >>>>>>> Ok, I can send the frame number changes tomorrow. When do you plan to >>>>>>> do >>>>>>> the actual bump? I assumed the last 5.x release should be branched >>>>>>> first. >>>>>> >>>>>> Why? 5.1 was already branched out. >>>>> >>>>> And is missing 6 months of development. >>>> >>>> So you want us to release both 6.0 and 5.2 at the same time? >>>> I don't get it. >>> >>> So user do not need to immediately update code that uses old API to >>> get new fancy features. >> >> And when do you stop doing this? > > After 6.0 tagged. > >> Also, as 5.1 is LTS, is 5.2 LTS too? >> > > No, its not. So, we tag 5.2 out of master? Then bump, and tag 6.0 too? And then branch out 6.0?
On 1/25/23, Jean-Baptiste Kempf <jb@videolan.org> wrote: > > > On Wed, 25 Jan 2023, at 22:29, Paul B Mahol wrote: >> On 1/25/23, Jean-Baptiste Kempf <jb@videolan.org> wrote: >>> >>> >>> On Wed, 25 Jan 2023, at 22:20, Paul B Mahol wrote: >>>> On 1/25/23, Jean-Baptiste Kempf <jb@videolan.org> wrote: >>>>> On Wed, 25 Jan 2023, at 22:03, Marton Balint wrote: >>>>>> On Wed, 25 Jan 2023, Jean-Baptiste Kempf wrote: >>>>>> >>>>>>> On Wed, 25 Jan 2023, at 21:08, Marton Balint wrote: >>>>>>>> On Wed, 25 Jan 2023, James Almer wrote: >>>>>>>> >>>>>>>>> On 1/24/2023 12:45 PM, Anton Khirnov wrote: >>>>>>>>>> So to summarize the discussion so far: >>>>>>>>>> >>>>>>>>>> * nobody is strongly arguing for an instability period after the >>>>>>>>>> bump, >>>>>>>>>> and there are good reasons against it, therefore we should >>>>>>>>>> NOT >>>>>>>>>> have >>>>>>>>>> one >>>>>>>>>> >>>>>>>>>> * the bump can be done either as bump-then-remove or >>>>>>>>>> remove-then-bump >>>>>>>>>> * there are advantages and disadvantages for both of those, >>>>>>>>>> nobody >>>>>>>>>> expressed a strong preference for either, so you can keep >>>>>>>>>> this >>>>>>>>>> as >>>>>>>>>> is >>>>>>>>>> >>>>>>>>>> Please correct me if I misunderstood or missed something, or >>>>>>>>>> somebody >>>>>>>>>> has a new opinion. >>>>>>>>> >>>>>>>>> Since the instability period doesn't seem popular, if anyone has >>>>>>>>> some >>>>>>>>> patches >>>>>>>>> for ABI changes (enum value or field offset changes, removing >>>>>>>>> avpriv_ >>>>>>>>> functions we forgot about, etc), then please send them asap so i >>>>>>>>> can >>>>>>>>> push >>>>>>>>> them all at the same time. >>>>>>>> >>>>>>>> Ok, I can send the frame number changes tomorrow. When do you plan >>>>>>>> to >>>>>>>> do >>>>>>>> the actual bump? I assumed the last 5.x release should be branched >>>>>>>> first. >>>>>>> >>>>>>> Why? 5.1 was already branched out. >>>>>> >>>>>> And is missing 6 months of development. >>>>> >>>>> So you want us to release both 6.0 and 5.2 at the same time? >>>>> I don't get it. >>>> >>>> So user do not need to immediately update code that uses old API to >>>> get new fancy features. >>> >>> And when do you stop doing this? >> >> After 6.0 tagged. >> >>> Also, as 5.1 is LTS, is 5.2 LTS too? >>> >> >> No, its not. > > So, we tag 5.2 out of master? > Then bump, and tag 6.0 too? And then branch out 6.0? Yes, with all old API support removed. This is the new way! > > -- > Jean-Baptiste Kempf - President > +33 672 704 734 > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". >
On Wed, 25 Jan 2023, Jean-Baptiste Kempf wrote: > On Wed, 25 Jan 2023, at 22:03, Marton Balint wrote: >> On Wed, 25 Jan 2023, Jean-Baptiste Kempf wrote: >> >>> On Wed, 25 Jan 2023, at 21:08, Marton Balint wrote: >>>> On Wed, 25 Jan 2023, James Almer wrote: >>>> >>>>> On 1/24/2023 12:45 PM, Anton Khirnov wrote: >>>>>> So to summarize the discussion so far: >>>>>> >>>>>> * nobody is strongly arguing for an instability period after the bump, >>>>>> and there are good reasons against it, therefore we should NOT have >>>>>> one >>>>>> >>>>>> * the bump can be done either as bump-then-remove or remove-then-bump >>>>>> * there are advantages and disadvantages for both of those, nobody >>>>>> expressed a strong preference for either, so you can keep this as >>>>>> is >>>>>> >>>>>> Please correct me if I misunderstood or missed something, or somebody >>>>>> has a new opinion. >>>>> >>>>> Since the instability period doesn't seem popular, if anyone has some patches >>>>> for ABI changes (enum value or field offset changes, removing avpriv_ >>>>> functions we forgot about, etc), then please send them asap so i can push >>>>> them all at the same time. >>>> >>>> Ok, I can send the frame number changes tomorrow. When do you plan to do >>>> the actual bump? I assumed the last 5.x release should be branched first. >>> >>> Why? 5.1 was already branched out. >> >> And is missing 6 months of development. > > So you want us to release both 6.0 and 5.2 at the same time? > I don't get it. I don't see too much benefit in releasing 6.0 right now just because we bumped API, beacuse API bump typically means API removal, not addition. So my suggestion is to release 5.2, then bump, then release 6.0 in a few months. As I said, this allow things to calm down after the bump, which I find good practice even if we do not have a formal unstable period. This is quite in line with what James proposed with 3 point releases: x.0 - first release after API break x.1 - LTS x.2 - last release before API break Regards, Marton
On Wed, 25 Jan 2023, at 23:28, Marton Balint wrote: > On Wed, 25 Jan 2023, Jean-Baptiste Kempf wrote: > >> On Wed, 25 Jan 2023, at 22:03, Marton Balint wrote: >>> On Wed, 25 Jan 2023, Jean-Baptiste Kempf wrote: >>> >>>> On Wed, 25 Jan 2023, at 21:08, Marton Balint wrote: >>>>> On Wed, 25 Jan 2023, James Almer wrote: >>>>> >>>>>> On 1/24/2023 12:45 PM, Anton Khirnov wrote: >>>>>>> So to summarize the discussion so far: >>>>>>> >>>>>>> * nobody is strongly arguing for an instability period after the bump, >>>>>>> and there are good reasons against it, therefore we should NOT have >>>>>>> one >>>>>>> >>>>>>> * the bump can be done either as bump-then-remove or remove-then-bump >>>>>>> * there are advantages and disadvantages for both of those, nobody >>>>>>> expressed a strong preference for either, so you can keep this as >>>>>>> is >>>>>>> >>>>>>> Please correct me if I misunderstood or missed something, or somebody >>>>>>> has a new opinion. >>>>>> >>>>>> Since the instability period doesn't seem popular, if anyone has some patches >>>>>> for ABI changes (enum value or field offset changes, removing avpriv_ >>>>>> functions we forgot about, etc), then please send them asap so i can push >>>>>> them all at the same time. >>>>> >>>>> Ok, I can send the frame number changes tomorrow. When do you plan to do >>>>> the actual bump? I assumed the last 5.x release should be branched first. >>>> >>>> Why? 5.1 was already branched out. >>> >>> And is missing 6 months of development. >> >> So you want us to release both 6.0 and 5.2 at the same time? >> I don't get it. > > I don't see too much benefit in releasing 6.0 right now just because we > bumped API, beacuse API bump typically means API removal, not addition. Because that's what we agreed on? Do a major release every year in Dec/Jan with an ABI/API breakage at that time. If you want to do a 5.2, why not, but I don't see the need, especially if 5.1 is the LTS one. But why not... But not doing what we said about major releases is a big breakage of trust.
On Wed, 25 Jan 2023, Jean-Baptiste Kempf wrote: > On Wed, 25 Jan 2023, at 23:28, Marton Balint wrote: >> On Wed, 25 Jan 2023, Jean-Baptiste Kempf wrote: >> >>> On Wed, 25 Jan 2023, at 22:03, Marton Balint wrote: >>>> On Wed, 25 Jan 2023, Jean-Baptiste Kempf wrote: >>>> >>>>> On Wed, 25 Jan 2023, at 21:08, Marton Balint wrote: >>>>>> On Wed, 25 Jan 2023, James Almer wrote: >>>>>> >>>>>>> On 1/24/2023 12:45 PM, Anton Khirnov wrote: >>>>>>>> So to summarize the discussion so far: >>>>>>>> >>>>>>>> * nobody is strongly arguing for an instability period after the bump, >>>>>>>> and there are good reasons against it, therefore we should NOT have >>>>>>>> one >>>>>>>> >>>>>>>> * the bump can be done either as bump-then-remove or remove-then-bump >>>>>>>> * there are advantages and disadvantages for both of those, nobody >>>>>>>> expressed a strong preference for either, so you can keep this as >>>>>>>> is >>>>>>>> >>>>>>>> Please correct me if I misunderstood or missed something, or somebody >>>>>>>> has a new opinion. >>>>>>> >>>>>>> Since the instability period doesn't seem popular, if anyone has some patches >>>>>>> for ABI changes (enum value or field offset changes, removing avpriv_ >>>>>>> functions we forgot about, etc), then please send them asap so i can push >>>>>>> them all at the same time. >>>>>> >>>>>> Ok, I can send the frame number changes tomorrow. When do you plan to do >>>>>> the actual bump? I assumed the last 5.x release should be branched first. >>>>> >>>>> Why? 5.1 was already branched out. >>>> >>>> And is missing 6 months of development. >>> >>> So you want us to release both 6.0 and 5.2 at the same time? >>> I don't get it. >> >> I don't see too much benefit in releasing 6.0 right now just because we >> bumped API, beacuse API bump typically means API removal, not addition. > > Because that's what we agreed on? > Do a major release every year in Dec/Jan with an ABI/API breakage at that time. > > If you want to do a 5.2, why not, but I don't see the need, especially if 5.1 is the LTS one. But why not... > But not doing what we said about major releases is a big breakage of trust. Okay, maybe its just me, but I missed this decision, and I don't remember any discussions regarding it. Can you give me some pointers? Thanks, Marton
On Thu, Jan 26, 2023 at 12:25:39AM +0100, Marton Balint wrote: > > > On Wed, 25 Jan 2023, Jean-Baptiste Kempf wrote: > > > On Wed, 25 Jan 2023, at 23:28, Marton Balint wrote: > > > On Wed, 25 Jan 2023, Jean-Baptiste Kempf wrote: > > > > > > > On Wed, 25 Jan 2023, at 22:03, Marton Balint wrote: > > > > > On Wed, 25 Jan 2023, Jean-Baptiste Kempf wrote: > > > > > > > > > > > On Wed, 25 Jan 2023, at 21:08, Marton Balint wrote: > > > > > > > On Wed, 25 Jan 2023, James Almer wrote: > > > > > > > > > > > > > > > On 1/24/2023 12:45 PM, Anton Khirnov wrote: > > > > > > > > > So to summarize the discussion so far: > > > > > > > > > > > > > > > > > > * nobody is strongly arguing for an instability period after the bump, > > > > > > > > > and there are good reasons against it, therefore we should NOT have > > > > > > > > > one > > > > > > > > > > > > > > > > > > * the bump can be done either as bump-then-remove or remove-then-bump > > > > > > > > > * there are advantages and disadvantages for both of those, nobody > > > > > > > > > expressed a strong preference for either, so you can keep this as > > > > > > > > > is > > > > > > > > > > > > > > > > > > Please correct me if I misunderstood or missed something, or somebody > > > > > > > > > has a new opinion. > > > > > > > > > > > > > > > > Since the instability period doesn't seem popular, if anyone has some patches > > > > > > > > for ABI changes (enum value or field offset changes, removing avpriv_ > > > > > > > > functions we forgot about, etc), then please send them asap so i can push > > > > > > > > them all at the same time. > > > > > > > > > > > > > > Ok, I can send the frame number changes tomorrow. When do you plan to do > > > > > > > the actual bump? I assumed the last 5.x release should be branched first. > > > > > > > > > > > > Why? 5.1 was already branched out. > > > > > > > > > > And is missing 6 months of development. > > > > > > > > So you want us to release both 6.0 and 5.2 at the same time? > > > > I don't get it. > > > > > > I don't see too much benefit in releasing 6.0 right now just because we > > > bumped API, beacuse API bump typically means API removal, not addition. > > > > Because that's what we agreed on? > > Do a major release every year in Dec/Jan with an ABI/API breakage at that time. > > > > If you want to do a 5.2, why not, but I don't see the need, especially if 5.1 is the LTS one. But why not... I can branch release/5.2 and make a release if theres agreement on that ? I dont think we should tag a release on master that will make point releases a mess as we need a branch for them I can also make a release/6.0 and release after the bump but it feels a bit like there should be a bit time between the bump and the release so teh codebase is tested a bit after ABI/API changes > > But not doing what we said about major releases is a big breakage of trust. > > Okay, maybe its just me, but I missed this decision, and I don't remember > any discussions regarding it. Can you give me some pointers? I think in general these are the constraints to optimize our release timing against: 1. We seem to want 2 releases per year 2. If we do a major bump, it should ideally happen after a release not before to give time for stabilization and to give max features to the old API/ABI 3. The releases which get into distros should be LTS 4. LTS releases should be timed so that they are getting into major distros 5. What gets into major distros should have maximum features and maximum stability 6. We should try to stick to what we said previously 7. We should have a predictable release cycle Some of these points are easy, some are a bit harder. to do 4. we (or i) need to know when the window is for distros to pick our release up, this should ideally leave time for a point release in case theers something major that needs fixing. I think someone should document these time windows for major distros somewhere like on trac so we all know what we are aiming for and why Now about 6. i asked google about ffmpeg release cycle it pointed me to a ffmpeg-user post from 2014 https://ffmpeg.org/pipermail/ffmpeg-user/2014-March/020558.html but that points more to git master than a release cycle another link goes to wikipedia "The project publishes a new release every three months on average. While release versions are available from the website for download, FFmpeg developers recommend that users compile the software from source using the latest build from their source code Git version control system" i have the feeling i will leave that resolution to someone else :) but iam happy to make releases every 6 or 3 months, later would be more work of course. So what do people think ? when should i branch 5.2, when 6.0 ? and when 6.1 and then 6.2 or 7.0 when ? also which should be LTS ? Btw, did we say that we will bump API/ABI in 6.0 or just that we will make 6.0 in dec/jan ? Iam pretty bad at remembering these plans, my notes say 6.0 in dec 2022 but that was not done because it would have competed with the LTS for inclusion in distros thx [...]
On Thu, 26 Jan 2023, at 23:16, Michael Niedermayer wrote: > I think in general these are the constraints to optimize our release timing > against: > > 1. We seem to want 2 releases per year Yes. > 2. If we do a major bump, it should ideally happen after a release not > before to give time for stabilization and to give max features to the old > API/ABI We said that one of those release would break ABI and API, and that would be the one at the dec/jan time > 3. The releases which get into distros should be LTS Yes > 4. LTS releases should be timed so that they are getting into major > distros > 5. What gets into major distros should have maximum features and > maximum stability > 6. We should try to stick to what we said previously > 7. We should have a predictable release cycle > So what do people think ? > when should i branch 5.2, when 6.0 ? and when 6.1 and then 6.2 or 7.0 when ? > also which should be LTS ? We've had this discussion the last time, notably for whether we should make 5.0 an LTS or 5.1 an LTS and we said: 5.0 in jan 2022, 5.1 in July 2022 with LTS 6.0 in jan 2023, 6.1 in July 2023 7.0 in jan 2024, 7.1 in July 2023 with LTS We said 5.0, 6.0 and 7.0 would be allowed to break API/ABI, aka big-bumps. We said we could do more 5.x or 6.x releases, if we needed more than 2 releases per year. We discussed that at several developer meetings, including the last one we had, a few weeks ago. > Btw, did we say that we will bump API/ABI in 6.0 or just that we will make > 6.0 in dec/jan ? Both. > Iam pretty bad at remembering these plans, my notes say 6.0 in dec 2022 but > that was not done because it would have competed with the LTS for inclusion > in distros No, because distro take a LONG time to integrate releases, because of the software dependencies adaptations. So, in Feb, they will use the last release of the previous major branch (here, a 5.1). Tbh, I don't see why we should do a 5.2, seeing that 6.0 would be the same features-set with just the ABI change, aka removing deprecated symbols. Also, doing a 5.2 which would not be a LTS, while 5.1 is a LTS is not only very weird, but it also goes against what we said last time, that the last of the 5.x would be LTS (similar for 7.1). I would just merge the bump, then branch 6.0 branch and wait a few weeks before releasing 6.0. If some people strongly want a 5.2, branch 5.2 before the bump and do a release at the same time.
On Thu, Jan 26, 2023 at 11:49:14PM +0100, Jean-Baptiste Kempf wrote: > On Thu, 26 Jan 2023, at 23:16, Michael Niedermayer wrote: > > I think in general these are the constraints to optimize our release timing > > against: > > > > 1. We seem to want 2 releases per year > > Yes. > > > 2. If we do a major bump, it should ideally happen after a release not > > before to give time for stabilization and to give max features to the old > > API/ABI > > We said that one of those release would break ABI and API, and that would be the > one at the dec/jan time > > > 3. The releases which get into distros should be LTS > > Yes > > > 4. LTS releases should be timed so that they are getting into major > > distros > > 5. What gets into major distros should have maximum features and > > maximum stability > > 6. We should try to stick to what we said previously > > 7. We should have a predictable release cycle > > > > So what do people think ? > > when should i branch 5.2, when 6.0 ? and when 6.1 and then 6.2 or 7.0 when ? > > also which should be LTS ? > > We've had this discussion the last time, notably for whether we should make 5.0 an LTS or 5.1 an LTS and we said: > 5.0 in jan 2022, 5.1 in July 2022 with LTS > 6.0 in jan 2023, 6.1 in July 2023 > 7.0 in jan 2024, 7.1 in July 2023 with LTS > > We said 5.0, 6.0 and 7.0 would be allowed to break API/ABI, aka big-bumps. > > We said we could do more 5.x or 6.x releases, if we needed more than 2 releases per year. > > We discussed that at several developer meetings, including the last one we had, a few weeks ago. > > > Btw, did we say that we will bump API/ABI in 6.0 or just that we will make > > 6.0 in dec/jan ? > > Both. > > > Iam pretty bad at remembering these plans, my notes say 6.0 in dec 2022 but > > that was not done because it would have competed with the LTS for inclusion > > in distros > > No, because distro take a LONG time to integrate releases, because of the software dependencies adaptations. > So, in Feb, they will use the last release of the previous major branch (here, a 5.1). > > Tbh, I don't see why we should do a 5.2, seeing that 6.0 would be the same features-set with just the ABI change, aka removing deprecated symbols. > > Also, doing a 5.2 which would not be a LTS, while 5.1 is a LTS is not only very weird, but it also goes against what we said last time, that the last of the 5.x would be LTS (similar for 7.1). > > I would just merge the bump, then branch 6.0 branch and wait a few weeks before releasing 6.0. > If some people strongly want a 5.2, branch 5.2 before the bump and do a release at the same time. ok I would suggest one thing, if people want a bump between 2023 6.0 and 2024 7.0 then the bump should happen closer to 6.1 than 7.0 thx [...]
On Fri, 27 Jan 2023, at 00:19, Michael Niedermayer wrote: > On Thu, Jan 26, 2023 at 11:49:14PM +0100, Jean-Baptiste Kempf wrote: >> On Thu, 26 Jan 2023, at 23:16, Michael Niedermayer wrote: >> > I think in general these are the constraints to optimize our release timing >> > against: >> > >> > 1. We seem to want 2 releases per year >> >> Yes. >> >> > 2. If we do a major bump, it should ideally happen after a release not >> > before to give time for stabilization and to give max features to the old >> > API/ABI >> >> We said that one of those release would break ABI and API, and that would be the >> one at the dec/jan time >> >> > 3. The releases which get into distros should be LTS >> >> Yes >> >> > 4. LTS releases should be timed so that they are getting into major >> > distros >> > 5. What gets into major distros should have maximum features and >> > maximum stability >> > 6. We should try to stick to what we said previously >> > 7. We should have a predictable release cycle >> >> >> > So what do people think ? >> > when should i branch 5.2, when 6.0 ? and when 6.1 and then 6.2 or 7.0 when ? >> > also which should be LTS ? >> >> We've had this discussion the last time, notably for whether we should make 5.0 an LTS or 5.1 an LTS and we said: >> 5.0 in jan 2022, 5.1 in July 2022 with LTS >> 6.0 in jan 2023, 6.1 in July 2023 >> 7.0 in jan 2024, 7.1 in July 2023 with LTS >> >> We said 5.0, 6.0 and 7.0 would be allowed to break API/ABI, aka big-bumps. >> >> We said we could do more 5.x or 6.x releases, if we needed more than 2 releases per year. >> >> We discussed that at several developer meetings, including the last one we had, a few weeks ago. >> >> > Btw, did we say that we will bump API/ABI in 6.0 or just that we will make >> > 6.0 in dec/jan ? >> >> Both. >> >> > Iam pretty bad at remembering these plans, my notes say 6.0 in dec 2022 but >> > that was not done because it would have competed with the LTS for inclusion >> > in distros >> >> No, because distro take a LONG time to integrate releases, because of the software dependencies adaptations. >> So, in Feb, they will use the last release of the previous major branch (here, a 5.1). >> >> Tbh, I don't see why we should do a 5.2, seeing that 6.0 would be the same features-set with just the ABI change, aka removing deprecated symbols. >> >> Also, doing a 5.2 which would not be a LTS, while 5.1 is a LTS is not only very weird, but it also goes against what we said last time, that the last of the 5.x would be LTS (similar for 7.1). >> >> I would just merge the bump, then branch 6.0 branch and wait a few weeks before releasing 6.0. >> If some people strongly want a 5.2, branch 5.2 before the bump and do a release at the same time. > > ok > I would suggest one thing, if people want a bump between 2023 6.0 and 2024 7.0 > then the bump should happen closer to 6.1 than 7.0 That is a very fair point, and we should do that next time, to avoid the current mess. I'm probably partly at fault, here. Sorry.
On 1/26/2023 7:49 PM, Jean-Baptiste Kempf wrote: > Tbh, I don't see why we should do a 5.2, seeing that 6.0 would be the same features-set with just the ABI change, aka removing deprecated symbols. > > Also, doing a 5.2 which would not be a LTS, while 5.1 is a LTS is not only very weird, but it also goes against what we said last time, that the last of the 5.x would be LTS (similar for 7.1). The idea of making one last release before the major bump was to give users "stuck" with a given soname something with the latest development. For example, Debian will allegedly ship 5.1 with bookworm (soft freeze is in two weeks). Users could then drop 5.2 libraries on their system without having to also recompile every single package that depends on ffmpeg. This used to be the case when our release schedule was not really set in stone and a release was considered LTS when distros happened to ship it. So i guess that yes, from now we should effectively make the LTS the last release of a given soname, and do the bump soon after it. An hypothetical 5.2 would not get support for too long and eventually it will become less secure to drop them into a bookworm system just to get some extra features added in the past few months.