Le ven. 2 avr. 2021 à 13:30, Slawomir Jaranowski <s.jaranow...@gmail.com> a écrit :
> From a maven user, plugin developer perspective it is not important for me > if I upgrade maven to 3.6.x or 3.8.x if I have changelog for it. > > More important is to know some of the release and support policies. > In other words, to know which version can contain new features, which only > bug fix, security updates and which version is not maintained any more. > > I see that without such a policy you don't agree with yourself. > As many ideas as many people for a version number ... > Exactly, it is what I tried to write in the next release version thread. It is fine to do jumps and not respect maintenance branches for end users while documented upfront but not after. As of today maven has no versioning policy and tend to communicate over something close to semver on the list - which is not respected in practise sadly. So teams pick a version with semver like in mind assuming they will get security fixes in this branch for the duration of the projects which tend to be wrong since maven tends to update minor as often as patch digit. So overall for this time we should just let a 3.6.4 go out to mitigate the side effect of this issue but after *and before any other release* we must clarify our versioning policy - minimum being what about security fixes (even if we say we only rely on major). > > pt., 2 kwi 2021 o 12:44 Robert Scholte <rfscho...@apache.org> napisał(a): > > > If you're speaking on behalf of others, please let those people explain > > their situation. So far I've only heard you, that's not enough for me to > > support a backport. > > > > Robert > > On 2-4-2021 11:01:12, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > > Le ven. 2 avr. 2021 à 10:44, Robert Scholte a écrit : > > > > > I think there are a couple of issues here: > > > - To me this shouldn't be done with a PR, but as a set of cherry-picks > to > > > keep to original commit history and references. > > > > > > > Was the way it was created, PR is just to share it there. > > > > > > > - Branch 3.6.x contains commits that are unrelated to the 3.8.x branch > > > > > > > Not sure what you have in mind behind that except that if so 3.8 can need > > to be updated - but not sure I got it right. > > > > > > > - I still don't see the need for this backport. I really doubt that > > people > > > would pick the possible 3.6.4 over 3.8.1 if they want to protect > > themselves > > > and do the configuration themselves. As you keep pushing for such a > > > release, please let the community comment (including why they need it > and > > > why using 3.8.1 is not an option) on MNG-7134[1] first. > > > > > > > I don't doubt about it, I have some contacts needing to stick to 3.6 + be > > CVE free at the same time for at least the coming 2 years, just trying to > > make these users happy. > > I already explained in previous posts why it was saner to do it on maven > > side (to avoid forks mainly which can lead to different "fixes" and > > behaviors - already saw it by the past + keep the common maven tooling as > > sdkman and ides plain support). > > > > > > > > > > Robert > > > > > > [1] https://issues.apache.org/jira/browse/MNG-7134 > > > On 2-4-2021 09:21:04, Romain Manni-Bucau wrote: > > > Hi all, > > > > > > As explained in another thread, I created > > > https://github.com/apache/maven/pull/462 to backport the security fix > on > > > 3.8 in 3.6.x. > > > Anyone able to review it? > > > Only change is that the default configuration is not there but it can > be > > > enabled - idea is to document it instead of breaking by default. > > > > > > Romain Manni-Bucau > > > @rmannibucau | Blog > > > | Old Blog > > > | Github | > > > LinkedIn | Book > > > > > > > > > > > -- > Sławomir Jaranowski >
