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 <[email protected]> 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>> >
