| Message ID | 20220716150924.13520-1-michael@niedermayer.cc |
|---|---|
| State | New |
| Headers | show |
| Series | [FFmpeg-devel] RELEASE_NOTES: Based on the version from 5.0 | expand |
| Context | Check | Description |
|---|---|---|
| yinshiyou/make_loongarch64 | success | Make finished |
| yinshiyou/make_fate_loongarch64 | success | Make fate finished |
| andriy/make_x86 | success | Make finished |
| andriy/make_fate_x86 | success | Make fate finished |
Op za 16 jul. 2022 om 17:09 schreef Michael Niedermayer < michael@niedermayer.cc>: > + ┌────────────────────────────────────────────┐ > + │ RELEASE NOTES for FFmpeg 5.1 "Riemann" LTS │ > + └────────────────────────────────────────────┘ > + > Should there perhaps be an explanation on what the LTS designation means in practice? Maybe at least mention that it is an abbreviation for long term support? I see that 2.8 still gets updates while it was first released almost 7 years ago, without any explanation people might expect LTS to mean (much) longer than that. Even if no definitive dates can be supplied, it might be possible to provide some guidance on this.
On Sat, Jul 16, 2022 at 10:05:15PM +0200, Martijn van Beurden wrote: > Op za 16 jul. 2022 om 17:09 schreef Michael Niedermayer < > michael@niedermayer.cc>: > > > + ┌────────────────────────────────────────────┐ > > + │ RELEASE NOTES for FFmpeg 5.1 "Riemann" LTS │ > > + └────────────────────────────────────────────┘ > > + > > > > Should there perhaps be an explanation on what the LTS designation means in > practice? Maybe at least mention that it is an abbreviation for long term > support? I see that 2.8 still gets updates while it was first released > almost 7 years ago, without any explanation people might expect LTS to mean > (much) longer than that. Even if no definitive dates can be supplied, it > might be possible to provide some guidance on this. something like this: ? + The FFmpeg Project proudly presents FFmpeg 5.1 "Riemann" LTS, about 6 + months after the release of FFmpeg 5.0, our first Long Term Support + release. About guidance, i really dont know what to write thx [...]
Op za 16 jul. 2022 om 22:36 schreef Michael Niedermayer < michael@niedermayer.cc>: > > something like this: ? > > + The FFmpeg Project proudly presents FFmpeg 5.1 "Riemann" LTS, about 6 > + months after the release of FFmpeg 5.0, our first Long Term Support > + release. > > Yes, that probably helps avoid any confusion on whether LTS here might mean something different. > > About guidance, i really dont know what to write > > I don't know what the reason was to call this release LTS. I know most people using ffmpeg are using the latest git anyway, but if I were to value stable releases and seeing that this release is LTS, I would wonder: how long is long term in this context (2 year, 5 years) and does it just mean long term security updates or can I expect backports as well? Without any detail, I think the designation LTS raises more questions than it answers. I think it is important to manage expectations here, people might expect certain aspects of this release to be kept up-to-date which were never intended to be part of the 'support'. I know this is all quite vague, but repeating myself: I don't know the rationale for this release being designated LTS, so I can't come up with something either. I see there are 9 releases that got updates in the last 2 months. If the LTS designation is meant to, going forward, lower the number of releases that get support for such a long time, this is something that can be stated as well. Something like: "to keep the amount of work to maintain releases reasonable, going forward only LTS releases can be expected to get security updates for more than 1 year." Just some thoughts.
On Sat, Jul 16, 2022 at 11:02:48PM +0200, Martijn van Beurden wrote: > Op za 16 jul. 2022 om 22:36 schreef Michael Niedermayer < > michael@niedermayer.cc>: > > > > > something like this: ? > > > > + The FFmpeg Project proudly presents FFmpeg 5.1 "Riemann" LTS, about 6 > > + months after the release of FFmpeg 5.0, our first Long Term Support > > + release. > > > > > Yes, that probably helps avoid any confusion on whether LTS here might mean > something different. > > > > > > About guidance, i really dont know what to write > > > > > I don't know what the reason was to call this release LTS. I know most > people using ffmpeg are using the latest git anyway, but if I were to value > stable releases and seeing that this release is LTS, I would wonder: how > long is long term in this context (2 year, 5 years) and does it just mean > long term security updates or can I expect backports as well? Without any > detail, I think the designation LTS raises more questions than it answers. > I think it is important to manage expectations here, people might expect > certain aspects of this release to be kept up-to-date which were never > intended to be part of the 'support'. > > I know this is all quite vague, but repeating myself: I don't know the > rationale for this release being designated LTS, so I can't come up with > something either. > > I see there are 9 releases that got updates in the last 2 months. If the > LTS designation is meant to, going forward, lower the number of releases > that get support for such a long time, this is something that can be stated > as well. Something like: "to keep the amount of work to maintain releases > reasonable, going forward only LTS releases can be expected to get security > updates for more than 1 year." > > Just some thoughts. ATM we have to maintain many releases because each is used by some distro the LTS designation might cause distros to coalescence onto fewer releases This may also make life easier to distro maintainers I dont think ita a big effect for anyone though. Also people asked for calling some releases "LTS". I mean the impact of maintaining lets say 4.2 if you maintain 4.1 and 4.3 already is small. a 4.2 rarely really needs something that isnt also needed by either 4.1 or 4.3 I cant say what others are doing or planing to do. I dont plan to do more or different things with releases actually used by distros. It just seems we will have fewer non LTS releases which will require long term support from us thx [...]
Op zo 17 jul. 2022 om 00:50 schreef Michael Niedermayer < michael@niedermayer.cc>: > ATM we have to maintain many releases because each is used by some distro > the LTS designation might cause distros to coalescence onto fewer releases > This may also make life easier to distro maintainers > Then maybe this can be placed in the release notes + The FFmpeg Project proudly presents FFmpeg 5.1 "Riemann" LTS, about 6 + months after the release of FFmpeg 5.0, our first Long Term Support + release. While several past FFmpeg releases have enjoyed long term support, + this is the first release where such an intention is made clear at release.
Maybe some highlights of this release? Like the biggest changes and improvements? On Sat, 16 Jul 2022, at 17:09, Michael Niedermayer wrote: > Name suggested by Leo Izen and Andreas Rheinhardt > > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc> > --- > RELEASE_NOTES | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > create mode 100644 RELEASE_NOTES > > diff --git a/RELEASE_NOTES b/RELEASE_NOTES > new file mode 100644 > index 0000000000..767eb4992f > --- /dev/null > +++ b/RELEASE_NOTES > @@ -0,0 +1,15 @@ > + > + ┌────────────────────────────────────────────┐ > + │ RELEASE NOTES for FFmpeg 5.1 "Riemann" LTS │ > + └────────────────────────────────────────────┘ > + > + The FFmpeg Project proudly presents FFmpeg 5.1 "Riemann", about 6 > + months after the release of FFmpeg 5.0. > + > + A complete Changelog is available at the root of the project, and the > + complete Git history on https://git.ffmpeg.org/gitweb/ffmpeg.git > + > + We hope you will like this release as much as we enjoyed working on it, and > + as usual, if you have any questions about it, or any FFmpeg related topic, > + feel free to join us on the #ffmpeg IRC channel (on irc.libera.chat) or ask > + on the mailing-lists. > -- > 2.17.1 > > _______________________________________________ > 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 Sun, Jul 17, 2022 at 10:43:02AM +0200, Jean-Baptiste Kempf wrote:
> Maybe some highlights of this release? Like the biggest changes and improvements?
Isnt that what Changelog is already doing ?
If not i would suggest to push the RELEASE_NOTES and let people add what they
feel merrits to be mentioned there
thx
[...]
Quoting Michael Niedermayer (2022-07-17 16:23:40) > On Sun, Jul 17, 2022 at 10:43:02AM +0200, Jean-Baptiste Kempf wrote: > > Maybe some highlights of this release? Like the biggest changes and improvements? > > Isnt that what Changelog is already doing ? By tradition, only certain things get mentioned in Changelog, like new codecs/(de)muxers/filters and such. Things like API changes, performance improvements, or other significant changes that are not one of the above, do not get mentioned. We might want to change that.
On Mon, Jul 18, 2022 at 01:39:47PM +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2022-07-17 16:23:40) > > On Sun, Jul 17, 2022 at 10:43:02AM +0200, Jean-Baptiste Kempf wrote: > > > Maybe some highlights of this release? Like the biggest changes and improvements? > > > > Isnt that what Changelog is already doing ? > > By tradition, only certain things get mentioned in Changelog, like new > codecs/(de)muxers/filters and such. Things like API changes, performance > improvements, or other significant changes that are not one of the > above, do not get mentioned. We might want to change that. i agree [...]
On Sun, Jul 17, 2022 at 10:01:19AM +0200, Martijn van Beurden wrote: > Op zo 17 jul. 2022 om 00:50 schreef Michael Niedermayer < > michael@niedermayer.cc>: > > > ATM we have to maintain many releases because each is used by some distro > > the LTS designation might cause distros to coalescence onto fewer releases > > This may also make life easier to distro maintainers > > > > Then maybe this can be placed in the release notes > > + The FFmpeg Project proudly presents FFmpeg 5.1 "Riemann" LTS, about 6 > + months after the release of FFmpeg 5.0, our first Long Term Support > + release. While several past FFmpeg releases have enjoyed long term > support, > + this is the first release where such an intention is made clear at > release. will apply with this change thx [...]
diff --git a/RELEASE_NOTES b/RELEASE_NOTES new file mode 100644 index 0000000000..767eb4992f --- /dev/null +++ b/RELEASE_NOTES @@ -0,0 +1,15 @@ + + ┌────────────────────────────────────────────┐ + │ RELEASE NOTES for FFmpeg 5.1 "Riemann" LTS │ + └────────────────────────────────────────────┘ + + The FFmpeg Project proudly presents FFmpeg 5.1 "Riemann", about 6 + months after the release of FFmpeg 5.0. + + A complete Changelog is available at the root of the project, and the + complete Git history on https://git.ffmpeg.org/gitweb/ffmpeg.git + + We hope you will like this release as much as we enjoyed working on it, and + as usual, if you have any questions about it, or any FFmpeg related topic, + feel free to join us on the #ffmpeg IRC channel (on irc.libera.chat) or ask + on the mailing-lists.
Name suggested by Leo Izen and Andreas Rheinhardt Signed-off-by: Michael Niedermayer <michael@niedermayer.cc> --- RELEASE_NOTES | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 RELEASE_NOTES