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 <thecakeisn...@gmail.com> 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 <r...@gmail.com> 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 <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 > >> > > > > -- Arnaud Héritier Twitter/Skype : aheritier
