I'm preparing the 3.8.1 release
So far I see no reason to backport some changes to a possible 3.6.4.
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 <[email protected]> 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-performance
> > >>
> >
> > >
> >
>
>
> --
> Arnaud Héritier
> Twitter/Skype : aheritier
>

Reply via email to