FWIW, I prefer that a project (any project, not just Maven) have a documented versioning policy that says something like “We use Semantic Versioning [1]. We don’t skip version numbers for things someone said a future release might contain. We do have guidance that specifies what is guaranteed to be backward compatible and what is not. That guidance is …”.
That said, a release manager is pretty much always free to do what they choose. It is up to the PMC to accept or reject a release based on whatever criteria the PMC has decided upon. In the end though, I am going to support those who are doing the hard work. Ralph [1] https://semver.org/ > On Apr 20, 2021, at 11:12 AM, Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > > 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 >>>> >>>> >>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
