On Sun, Jul 13, 2025 at 07:09:13PM +0200, Marton Balint wrote:
> 
> 
> On Fri, 11 Jul 2025, Michael Niedermayer wrote:
> 
> > On Fri, Jul 11, 2025 at 10:29:30AM +0200, Nicolas George wrote:
> > > Michael Niedermayer (HE12025-07-11):
> > > > ok, chanegd it to AVERROR_INVALIDDATA
> > > 
> > > Thanks.
> > > 
> > > > Yes
> > > > but this also affects releases, and adding a field to AVFormatContext
> > > > is an issue for releases as it changes ABI
> > > > 
> > > > So the concat patch would go into old release branches and the
> > > > AVFormatContext one into master
> > > > Unless someone has a better idea ...
> > > 
> > > What happened to being able to add fields at the end?
> > 
> > a release branch might have a libavformat with version
> > 1.2.3
> > 
> > the next release branch  might have a libavformat with version
> > 1.5.2
> > 
> > The problem is if we add a field to 1.2.3 (which would become 1.3.0)
> > ABI/API requires that field to be in 1.5.2, but it is not
> > 
> > Also besides this problem, 1.3.0 on git masters history likely
> > added something thats not on the release branches 1.3.0
> > 
> > So, adding at the end is perfectly fine on the linear history
> > on git master but our release branches, branch off that.
> > 
> > so we would have to hack around things if we really needed to
> > add a field, we could try to use 1.2.4 or even 1.2.3 with a new field
> > but this is wrong.
> 
> I always assumed that the whole point of bumping minor versions both before
> and after the release is to be able to bump micro in release branches if new
> option or a new public field is added in the release branch.

it could be (ab)used that way, yes

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire