Well, i'd like we close this topic by an action and not let it die if possible. That said, as mentionned originally, what I want we write and publish is what we guarantee. I tried to write what i'd like to see/would expect as an user but if the agreement is that there will be no guarantee i'm fine with that too - would be happy to have some help on the wording for such a statement though. This kind of statement also solves the issue and would close this thread for me.
I like the idea of Benjamin of listing support companies but I think it is worth another page maybe (linked from the previous one/history page Hervé mentionned). Would this kind of solution work for everybody? To be concrete: 1. we write on history page that there is no guarantee of version for a security fix (Ex: if the fix requires a new feature it will likely not hit a patch release but a minor one using semver semantic) 2. we create a support page Wdyt? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 20 avr. 2021 à 20:03, Benjamin Marwell <bmarw...@apache.org> a écrit : > 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 > > > > > > > > >
