I agree, maven does not need to concern itself with branches as long as it stays fairly forward drop-in compatible.
Having said that, things like changing the policy for handling http might not be that drop-in, but on the other hand it’s just a config option and does not require complicated (plugin) dependency updates. I do wonder if the version number should better reflect such incompatible requirement changes. (And if somebody really wants to provide security fixes for those incompatible older branches why not, but I don’t think you can require them from a project which does not offer them by themself). -- http://bernd.eckenfels.net ________________________________ Von: Ralph Goers <[email protected]> Gesendet: Sunday, April 4, 2021 9:55:50 PM An: Maven Developers List <[email protected]> Betreff: Re: Security/Versioning policy proposal More than likely you will get whatever the next version number happens to be. I can’t think of a case where Maven needed to go back and patch a prior release. That could happen however, if Maven was modified to require Java 11 to run and a security fix had to be applied to the last version supporting Java 8. Ralph > On Apr 4, 2021, at 6:25 AM, Romain Manni-Bucau <[email protected]> wrote: > > Le dim. 4 avr. 2021 à 14:10, Robert Scholte <[email protected]> a écrit : > >> To me all releases can contain security fixes. >> Depending on the risk of the CVE we can decide to do a release with only >> those fixes (see Maven 3.0.5 and 3.8.1) >> > > I get that but it does not help users to pick versions and to get any > stability in their build - which is the goal of this thread. > Since you rejected a 3.6.4 for last CVE hitting us I have to admit I have a > hard time to formalize it. > Best I come up is "we'll do what we want" which is hopefully just a > complete misinterpretation of what you mean but hope shows how clueless I > am with such a statement at the moment. > Can you try to refine it please? > > Concretely, today I'm starting with a 3.8.1, what am I expecting to use in > 5 years for this project trying to get security fixes and being stable (ie > 4.x is assumed excluded?)? > > >> >> Robert >> >> On 4-4-2021 12:14:39, Romain Manni-Bucau <[email protected]> wrote: >> Le dim. 4 avr. 2021 à 12:09, Robert Scholte a écrit : >> >>> I doubt we can or should make any promises, only intentions. >>> If we would have it, I wonder if it cover our choice to skip 3.7.0. >>> To me we need to keep that flexibility. >>> >>> I want to reverse the approach: what could users expect as differences >>> between version x and y. >>> >>> For Maven shouldn't be more complex than: >>> bugfix release-change should be safe "just replace" release with bugfixes >>> and internal improvements. >>> minor release-change should represent relevant new features or (as we saw >>> for 3.8.x) possible breaking builds that can be fixed with configuration. >>> major release-change represents changes to the architecture that might >>> change the behavior. >>> as far as I know this defends all Maven releases up until now. >>> >> >> Does not cover the last release - and is actually the issue I'm suffering >> from right now and why i'd like we cover this case: security fixes. As of >> today it is a mix between patch (bugfix) and minor lines AFAIK but I'd like >> we explicit it (even just saying on each line "can include bugfixes"). >> Said differently: the reverse approach you mention only cover the feature >> evolution but not the most important for versioning policy: the security >> policy which is the one which hurt right now. >> As an user, I want to be able to anticipate the versions i can need staying >> as much as possible on a stable version (original version) but upgrading to >> get security fixes. >> If it is fine for you to mention lines 1 and 2 can include security fixes >> i'd be to add this paragraph on the history page maybe? >> >> wdyt? >> >> >>> >>> In case of plugins: the major represents the minimal required version of >>> Maven. >>> >>> Robert >>> On 4-4-2021 11:28:30, Romain Manni-Bucau wrote: >>> Hi Elliotte, >>> >>> My goal is to write what we can promise and users can rely on to work. >>> If we can only promise any major release will get all security fixes >>> whatever are the minor/patch versions, be it. >>> I just want what we do to be explicit. >>> >>> Hervé proposed to reference history page of website, it can be a good >> start >>> with one or two more sentences to solve that. >>> >>> Le sam. 3 avr. 2021 à 23:50, Elliotte Rusty Harold a >>> écrit : >>> >>>> On Fri, Apr 2, 2021 at 4:21 PM Romain Manni-Bucau >>>> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> What about starting from something like >>>>> http://tomee.apache.org/security/security.html for our versioning >>>> policy. >>>>> >>>>> Goal is really to let user plan their versioning policy and ensure >>> there >>>> is >>>>> no big surprises in the needed upgrades to have bugfixes. >>>>> >>>> >>>> TBH I don't think we have enough developer time and commitment to >> promise >>>> this. >>>> >>>> -- >>>> Elliotte Rusty Harold >>>> [email protected] >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
