I don't get the reasoning: what content do you expect in such a Maven 3.6.4 release compared to 3.8.1? for what benefit?
Le mardi 30 mars 2021, 20:16:23 CEST Romain Manni-Bucau a écrit : > Le mar. 30 mars 2021 à 19:36, Robert Scholte <rfscho...@apache.org> a > > écrit : > > I'm preparing the 3.8.1 release > > So far I see no reason to backport some changes to a possible 3.6.4. > > ...provide a fixed version to at least our most recent+used version to > enable company policies to be respected with the security fix and avoid a > ton of forks/custom backports (users/community first). > I'm fine doing the release (at least the steps I can) but I would be very > disappointed maven is not able to give any versioning guarantee at all - or > we need to revise our versioning since for now there is no possible > anticipation for projects which is an issue for me. > > > Only in case we get enough requests from the community to do so, we might > > consider creating a partial backport. > > > > thanks, > > Robert > > On 30-3-2021 18:53:17, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > > Ok so seems 3.8.1 gets a lot of votes. > > Can we still do a 3.6.4/3.6.3.1 or whatever (3.6 branch is the important > > point as explained). > > > > Romain Manni-Bucau > > @rmannibucau | Blog > > > > | Old Blog > > | Github | > > > > LinkedIn | Book > > > > > > > > Le mar. 30 mars 2021 à 18:50, Arnaud Héritier a > > > > écrit : > > > Due to the distribution error, I agree that the next release can only be > > > 3.8.1 today > > > > > > On Tue, Mar 30, 2021 at 6:39 PM TheCakeIsNaOH > > > > > > wrote: > > > > Hi, > > > > > > > > I am the maintainer of the Maven Chocolatey package. > > > > > > > > Given that I uploaded a 3.8.0 package after seeing the binaries in the > > > > release > > > > download area, there are around ~2,400 users which downloaded that > > > > > > version > > > > > > > of the package. > > > > > > > > Therefore, on the Chocolatey side of things, it would be best if the > > > > next > > > > > > version > > > > is something greater than 3.8.0. That way, the people that downloaded > > > > the > > > > > > 3.8.0 package would upgrade to the actual release, instead of having > > > > to > > > > downgrade manually. > > > > > > > > Regards, TheCakeIsNaOH > > > > > > > > On 2021/03/28 09:47:11, Romain Manni-Bucau wrote: > > > > > Hi all,> > > > > > > > > > > Before we reroll the failed 3.8.0 I'd like we discuss openly the > > > > next> > > > > > > > versioning since it seems we didn't reach a consensus yet and trying > > > > to > > > > > > not> > > > > > > > > > create too much friction for users and in the community.> > > > > > > > > > > As a reminder the only feature the release will get is to prevent > > > > HTTP > > > > > > repo> > > > > > > > > > (in favor of HTTPS ones). In that regard it is a breaking change if > > > > > > > > users> > > > > > > > > > rely on HTTP repo but a security fix (I don't come back on the HTTP > > > > ->> > > > > > > > HTTPS move IT ecosystem got recently here).> > > > > > > > > > > So it seems there are multiple versioning options:> > > > > > > > > > > 1. 3.6.4: seems natural since it is a security fix, enables > > > > > companies > > > > > > to> > > > > > > > > get this fix respecting a project versioning policy without having > > > > to> > > > > > > > upgrade and avoids us to have to maintain 3.6 + 3.7/3.8 and soon > > > > 4.x.> > > > > > > > Indeed it requires a very well documented paragraph about this > > > > > change > > > > > > > > and> > > > > > > > > > how to workaround it (local proxy/mirror is a trivial one for > > > > example) > > > > > > but> > > > > > > > > > it will be the case whatever version we pick anyway IMHO.> > > > > > 2. 3.7.0: since it is a breaking change it can seem natural too (but > > > > > > has> > > > > > > > > the pitfall to likely require a backport in 3.6 anyway, due to the> > > > > > versioning policies which can prevent some users to upgrade to a > > > > 3.7)> > > > > > > > 3. 3.8.0: was the vote, seems the rational was that originally we> > > > > > targetting mvnw in 3.7 and since we didn't make it 3.8 was used. > > > > > Have > > > > > > to> > > > > > > > > admit I'm not sure of this reasoning more than that (cause for me if > > > > > > we> > > > > > > > > don't have a planned feature we can either try to push/wait for it > > > > or> > > > > > > > postpone it but not skip a version due to that) so if anyone wants > > > > to> > > > > > > > complete the reasoning here it would be great.> > > > > > > > > > > Indeed my preference is for 3.6.4 which has the most advantages for> > > > > > everyone and no additional drawbacks compared to 3.7 or 3.8 options > > > > > > > > until> > > > > > > > > > we try to push to get mvnw in which would mean 3.7 becomes more > > > > > > natural> > > > > > > > > (and likely imply a 3.6.x maintenance version).> > > > > > > > > > > Goal of this thread is to feel the overall trend and see if we can > > > > > > > > refine> > > > > > > > > > the proposals (for example: can we drop 3.8 one and only keep 3.7 > > > > > and > > > > > > > > 3.6> > > > > > > > > > or - best - can we refine it to a single version after some > > > > > > exchanges).> > > > > > > > > If we keep a few proposals after some days, what about a vote where > > > > > > the> > > > > > > > > majority wins - we would just need to define how we count,> > > > > > bindings/committers/all (my preference being last one indeed)?> > > > > > > > > > > Romain Manni-Bucau> > > > > > @rmannibucau | Blog> > > > > > > > > > > | Old Blog> > > > > > | Github > > > > > > > > https://github.com/rmannibucau> |> > > > > > > > > > LinkedIn | Book> > > > > https://www.packtpub.com/application-development/java-ee-8-high-performanc > > e > > > > > -- > > > Arnaud Héritier > > > Twitter/Skype : aheritier --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
