Well said Ralph :-) Gary
On Wed, Apr 21, 2021, 02:26 Ralph Goers <ralph.go...@dslextreme.com> wrote: > 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 > >
