While I would also be surprised if people are successfully running an unpatched version of 1.3.0, it seems like a circular dependency to decide which versions to support based on what people are using. People will generally prefer to use supported versions so our messaging here informs their decision.
I think the question to ask (which Pifta implied with the options presented) is how do we define support? Is it just security fixes, or also critical bug fixes (data loss or service outage) or even other more minor bug fixes? Given the speed that Ozone development and fixes are happening, we saw a comprehensive 1.3.1 bug fix release to be too large and that’s why the effort was abandoned. While a critical bug fix release might be more manageable, I haven’t seen an effort to initiate this in practice. Based on this experience, these seem like the two best options to me: 1. Define support as “security fixes only” and include support for 1.3.0 2. Define support as “security and critical bug fixes only” and drop support for 1.3.0 I am in favor of option 1 because I think the optics of completely dropping support for the immediately previous version are not good. Also due to the velocity that bug fixes are coming in, I don’t see us cherry-picking bug fixes to do a 1.4.1 release, but instead doing 1.5.0 from master. By defining support as “security only” we are being up-front with our intentions and upgrade recommendations, since as Stephen highlighted remaining on 1.3.0 is not recommended for stability. With either option, more frequent releases will help since we could support the last X versions, but those versions could still be less than a year old. Higher release frequency is a topic for another thread though. Ethan On Mon, Feb 12, 2024 at 3:00 AM Stephen O'Donnell <sodonn...@cloudera.com.invalid> wrote: > The first question I have is: > > Is anyone running 1.3.0 in production today? > > That release is over a year old and there are many known problems that have > been fixed on 1.4.0. I would be quite surprised if anyone is running 1.3.0 > successfully without some additional custom patches on top of it. If they > have a patched 1.3.0, then a new release won't help, as it would be easier > to just cherry pick the CVE fix on top of their custom build. > > > On Mon, Feb 12, 2024 at 10:39 AM István Fajth <fapi...@gmail.com> wrote: > > > Hi developers, > > > > Me and Attila had a discussion about a PR > > <https://github.com/apache/ozone/pull/6100> that is posted by > @ivandika3. > > > > In our SECURITY.md file we have a table about our supported versions. > > In light of the recent CVE, the idea is to remove the supported flag from > > any release prior to 1.3.0, and leave 1.3.0 and 1.4.0 supported. > > > > I tend to believe this is something that is reasonable considering that > > 1.2.1 is over 2 years old. > > > > However, leaving 1.3.0 supported means that we should release 1.3.1 in > > order to have the recently released CVE-2023-39196 fixed for the 1.3.x > > line. > > There was an effort earlier to release 1.3.1, but we have abandoned that > > effort. > > > > *What do you think, which way should we manage this?* > > 1. Leave 1.3.1 branch as it is cherry-pick the CVE fix, and release it? > > 2. Leave 1.3.1 alone, and release the fix for the CVE from a new branch > as > > (a) 1.3.0.1, or (b)1.3.2? > > 3. Prepare a proper 1.3.1 release with all the critical fixes that we > have, > > including the fix for the CVE? > > 4. Mark 1.3.0 unsupported which is also something that I can imagine, > > however that release is just over 1 year old. > > > > A minimalistic approach - As we dropped the idea of 1.3.1 already - to > just > > go with 2a. > > The simplest is to choose to drop support for 1.3.0. > > If we support 1.3.0 today, and we want to do it right, then releasing > 1.3.1 > > in the next 1-2 weeks seems to be the proper approach. > > > > I am +1 for all these 3 approaches and I am not against the approach > listed > > in point 1., however I do not support it either. > > I can not - at the moment - take on a full 1.3.1 release, so if the > > community decides to go that route, we will need a release manager also > for > > that. > > > > What I can volunteer for, is to update the SECURITY.md based on the > > decision, and in case a minimalistic release approach is taken (2a or > 2b), > > I can take on releasing that. > > > > -- > > Pifta > > >
