"we must clarify our versioning policy" Hopefully semver-ish, hopefully not "burning" version numbers when a release candidate fails, that's crazy making for users, especially for a tool as critical as Maven
Gary On Fri, Apr 2, 2021, 07:44 Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > 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 > > >
