Le lun. 19 avr. 2021 à 17:20, Benjamin Marwell <bmarw...@apache.org> a écrit :
> > Do we write 3.6 and 4 are active and maintained branches currently or > do we > > drop 3.x with first 4.x release? > > Dropping 3.x with the first 4.x release would not make sense from the > point you presented earlier. > I'd drop 3.x as soon as we reach 4.1.0. > I can agree but it also means we define what is 4.1.0 and since we "jump" versions it will require us to better respect what we plan (I think it is very good, don't take it wrong). > > > maintenance branches on demands > My vote would be to cherry pick security fixes for the previous minor > version. > E.g. if we release 4.0.1, also release a 3.8.2 (assuming the current > latest versions are 4.0.0. and 3.8.1). > > I mean, we can try this for a single release and see if we like it. > If not, we can still drop this again and revert back to "on demand" > maintenance branches. > > Backporting features does not make sense (imo) how maven treats releases. > I think it is the whole point: what when we fix a security issue by a new feature -> "does not make sense" (quoting your words but that's what was the outcome for 3.8.1) and it is exactly the issue I face and I want we fix: no predictability on stable maven versions with a minimal maintenance "guaranteed" (no security issue opened in CVE databases). So I think we either write we backport the security fixes in last 2 maintained branches with some duration (we can align on java LTS duration for example which should be close to our major breaking changes) or we write we don't care and only maintain the last release branch and it is the only one guaranteed to get fixes (which kind of means there will be no anticipation of version but it is known upfront). Indeed I'm not a fan of such "you will see" policies but it clarifies the point which is my main blocker at the moment at least we can justify our last behavior. This is really the answer I'm after: explicit what we do and continue or make us more rigorous in the future. That said I note the "we can still revert back" point which is surely a very good one so idea can be to write "we will do xxxx" and add a banner on top saying "experimental policy until XXXX" (for example for a year) and we can change the policy (and update the deadline) within this duration if it does not fit. This would enable us to test and validate the policy with an error right and let the user know it upfront. So proposal can be: [Experimental policy until June 2022] 1. We maintain two major releases, ie 3.x and 4.x as of today (no minor in particular, just the highest one) 2. We maintain versions and notify the EOL 3 years before it is reached (so if we want to EOL v3 in 2025 we will notify users in 2022) 3. We backport and release security fixes (new feature or not) in all maintained branches Wdyt? > > Am So., 18. Apr. 2021 um 22:45 Uhr schrieb Romain Manni-Bucau > <rmannibu...@gmail.com>: > > > > Hi all, > > > > Back on this topic - which prepares v4 releases too btw. > > > > What do we finally write? > > > > That maven will always fix the latest (stable) version and can release > > maintenance branches on demands (lazily)? > > > > Do we write 3.6 and 4 are active and maintained branches currently or do > we > > drop 3.x with first 4.x release? > > > > Indeed I'd like the 2 branches option but I am fine with whatever policy > > while written and clear for end users upfront. I'd love we solve that > > before next release if possible cause it always create pointless work due > > to the blurry exchanges on this topic over our website and the net/mail > > archives. > > > > > > Le lun. 5 avr. 2021 à 19:51, Romain Manni-Bucau <rmannibu...@gmail.com> > a > > écrit : > > > > > > > > > > > > > > Le lun. 5 avr. 2021 à 17:42, Ralph Goers <ralph.go...@dslextreme.com> > a > > > écrit : > > > > > >> I don’t understand the point. The very next version of Maven did get > the > > >> security fix. Just because the release manager decided to follow a > peculiar > > >> version numbering practice unique to Maven doesn’t mean there is a > problem. > > >> > > > > > > This had been an issue only because the versioning policy of maven is > > > undefined. > > > If defined it is perfectly fine for me. > > > > > > > > >> > > >> I don’t know what you mean by random, nor do I know what you mean by a > > >> stability statement. AFAIK Maven has been very stable from the 2.x > versions > > >> through the 3.x versions. In some ways too stable, which is why > introducing > > >> new concepts that have been wanted for years is so hard. > > >> > > > > > > Last statements tend to mean that once 4.x will be there, 3.x will be > > > forgotten and no more maintained. > > > Since it is a breaking change and if you picked 3.x today it is a big > deal > > > since you have no guarantee you can upgrade without a lot of > investment and > > > get security fixes when needed by just upgrading (and potentially > tuning a > > > bit the conf but not by rewriting the poms for ex). > > > > > > For 2.x -> 3.x time, the 2.x was maintained some years. > > > This is very close to the LTS concept, and this is mainly this kind of > > > statement I'm trying to get to let projects plan properly and not have > > > maven on their road too easily. > > > If properly defined it will not impact much maven dev but can save a > lot > > > of time for enterprises and enable them to properly setup their > projects in > > > time. > > > > > > So overall the definition points are still the same: > > > > > > 1. which versions are maintained (ie can get security fixes - new > features > > > are not required to be in the box here) > > > 2. for how long > > > 3. what does mean version (major.minor.*, major.* for ex) in 1. > > > > > > "3.x will be supported for 3 more years when 4.x is out and maintained > > > major versions are guaranteed to get security fixes" is a kind of > statement > > > which solves that - we can also use N=current and N+1 in the statement > to > > > not stick it to 3 and 4. > > > "4.x is the current released branch, other branch will never be > released > > > anymore" does not work for me for example IMHO (but we can put it on > vote > > > if that's the community desire). > > > > > > > > >> > > >> FWIW, my employer’s repository manager still uses http since it is > behind > > >> a VPN. After trying 3.8.1 I found I had to specify mirrors for all the > > >> repos even though they are not defined in pom’s. Apparently the fix > also > > >> affects repositories defined in settings.xml. > > >> > > > > > > Yes because it is a mirror and wildcard one. > > > Using a custom global settings - to override default one - is a > solution > > > if you know all http repositories you want to force to be blocked (can > be > > > hard since you never know all of them by definition and mirroring does > not > > > support custom patterns but can be a quick workaround to upgrade > without > > > blocking builds). > > > > > > > > >> > > >> Ralph > > >> > > >> > On Apr 5, 2021, at 12:28 AM, Romain Manni-Bucau < > rmannibu...@gmail.com> > > >> wrote: > > >> > > > >> > Hmm, general/common asf way of doing is to move forward until users > ask > > >> > (and if so any branch is patched while a pr is done). > > >> > If maven does not follow that practise it cant say "last version > will > > >> get > > >> > the security fix" too because it means "we dont care of users, to > get > > >> the > > >> > cve fix you will have to rewrite your build". > > >> > So at least a major stability statement is required IMO with some > lts > > >> > statement and eol on majors. > > >> > Without that using maven sounds random for projects, no? > > >> > > > >> > Le dim. 4 avr. 2021 à 22:13, Bernd Eckenfels < > e...@zusammenkunft.net> a > > >> > écrit : > > >> > > > >> >> 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 <ralph.go...@dslextreme.com> > > >> >> Gesendet: Sunday, April 4, 2021 9:55:50 PM > > >> >> An: Maven Developers List <dev@maven.apache.org> > > >> >> 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 < > rmannibu...@gmail.com > > >> > > > >> >> wrote: > > >> >>> > > >> >>> 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 > > >> >>>>>> > > >> >>>>>> > > >> >>>>> > > >> >>>> > > >> >> > > >> >> > > >> >> > > >> >> > --------------------------------------------------------------------- > > >> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > >> >> For additional commands, e-mail: dev-h...@maven.apache.org > > >> >> > > >> >> > > >> > > >> > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > >> For additional commands, e-mail: dev-h...@maven.apache.org > > >> > > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
