Le dim. 4 avr. 2021 à 14:10, Robert Scholte <rfscho...@apache.org> 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 <rmannibu...@gmail.com> 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 > > > elh...@ibiblio.org > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > >
