I tend to agree to Robert, although I find your idea appealing and do understand the motivation.
If you look at some Eclipse projects, they also refer you to companies like IBM if you want anything beyond [1]. Ben [1]: e.g. https://adoptopenjdk.net/support.html On Tue, 20 Apr 2021, 19:55 Robert Scholte, <rfscho...@apache.org> wrote: > Romain, > > I still don't like this approach. > > What you're asking tend to look like contracts and SLA's and as long as > we're maintaining Maven with a very small group of volunteers and aren't > backed full time by some company we shouldn't do this. > If there are companies that use Maven and want this kind of commitment, we > need to start a different discussion. > E.g. could/should I (or any other Maven developer) start to offer Maven > Support contracts and under what conditions? > > Keep in mind that you are the only that keeps pushing this topic. > I noticed that it frustrates some and that it they loose their motivation > to work on Maven. > Please reconsider if it is still worth the discussion or that you can > solve it for yourself. > > thanks, > Robert > On 19-4-2021 20:05:53, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > Le lun. 19 avr. 2021 à 17:20, Benjamin Marwell 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 > > : > > > > > > 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 > > a > > > écrit : > > > > > > > > > > > > > > > > > > > Le lun. 5 avr. 2021 à 17:42, Ralph Goers > > 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 > > > >> >> Gesendet: Sunday, April 4, 2021 9:55:50 PM > > > >> >> An: Maven Developers List > > > >> >> 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 > > 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 > > > >> 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 > > > > >
