Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

[Hervé BOUTEMY]

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  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  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
> > > > 

Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

[Romain Manni-Bucau]

Le mar. 30 mars 2021 à 19:36, Robert Scholte  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  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
> >
>

Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

[Robert Scholte]

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  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
>

Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

[Romain Manni-Bucau]

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
>

Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

[Arnaud Héritier]

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

Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

[TheCakeIsNaOH]

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>>

>

Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

[Jesper Udby]

ng

encryption (HTTPS) as one means of security. Other strategies are

also

available. Only the CHECKSUM was supplied as means of data integrity

by

the

network Gods.

Anybody want to talk about intraprocess (tight coupling) and

Interprocess

(loose coupling) ?





On Sun, 28 Mar 2021, 15:39 Markus KARG, 

wrote:

Nonsense. It is common sense that most criminal acts are spawned

from

within the local network, due to social engineering.
-Markus


-Ursprüngliche Nachricht-
Von: Som Lima [mailto:somplastic...@gmail.com]
Gesendet: Sonntag, 28. März 2021 15:06
An: Maven Developers List
Betreff: Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or

other

BTW there should be an option to still use unsecure http as many

people

run http in their LANs.

I could be wrong but I think the intranet is a tightly coupled  comm

system

therefore it is secure by design.



On Sun, 28 Mar 2021, 13:31 Markus KARG, 

wrote:

We should not do any tricks or unexpected behavior but just stick

with

SemVer.
If there is a need for a security fix, it has to be 3.6.4 and BTW

there

should be an option to still use unsecure http as many people run

http

in

their LANs.
If it contains backwards-compatible features, it has to be 3.7.0.
If it breaks backwards-compatibility, it has to be 4.0.0.
In no case it can be 3.8.0.
If mvnw was proposed for 3.7 but is not here now, then we either

have

to

wait with 3.7.0, or we have to tell people that we move mvnw to

3.8

or

4.0.

I do not see a need for any discussion at all, as SemVer is pretty

clear

about the sole correct answer.
-Markus

-Ursprüngliche Nachricht-
Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
Gesendet: Sonntag, 28. März 2021 11:47
An: Maven Developers List
Betreff: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or

other

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



-

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org





-

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org




-

Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

[Romain Manni-Bucau]

; That said, having this kind of toggle pushes to 3.6.4 more than all
> >> others
> >>>> by design then, no?
> >>>>
> >>>> 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
> >>>>
> >>>> Le lun. 29 mars 2021 à 08:51, Som Lima  a
> >> écrit
> >>>> :
> >>>>
> >>>>> I thought we were talking about computer programming algorithms.
> >>>>>
> >>>>>
> >>>>> Social engineering  is outside the scope of the  discussion on the
> >>>> subject
> >>>>> of the  algorithm devised in the invisible ( to API developers),
> >> network
> >>>>> layer implementation.
> >>>>>
> >>>>> The  scope of discussion is that the intranet is a tightly coupled
> >> comm
> >>>>> system therefore secure by design.
> >>>>> Imagine a couple holding each other tightly so no intruder, (third
> >>>> party)
> >>>>> can  come in  between and interfere.
> >>>>>
> >>>>>
> >>>>> Meanwhile the internet  (loosely coupled) due to physical limitations
> >>>> could
> >>>>> not be implemented  using the same algorithm.
> >>>>> It was left to users  to work out the security which can be done
> using
> >>>>> encryption (HTTPS) as one means of security. Other strategies are
> also
> >>>>> available. Only the CHECKSUM was supplied as means of data integrity
> >> by
> >>>> the
> >>>>> network Gods.
> >>>>>
> >>>>> Anybody want to talk about intraprocess (tight coupling) and
> >>>> Interprocess
> >>>>> (loose coupling) ?
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Sun, 28 Mar 2021, 15:39 Markus KARG, 
> >> wrote:
> >>>>>> Nonsense. It is common sense that most criminal acts are spawned
> >> from
> >>>>>> within the local network, due to social engineering.
> >>>>>> -Markus
> >>>>>>
> >>>>>>
> >>>>>> -Ursprüngliche Nachricht-
> >>>>>> Von: Som Lima [mailto:somplastic...@gmail.com]
> >>>>>> Gesendet: Sonntag, 28. März 2021 15:06
> >>>>>> An: Maven Developers List
> >>>>>> Betreff: Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or
> >>>> other
> >>>>>>> BTW there should be an option to still use unsecure http as many
> >>>> people
> >>>>>> run http in their LANs.
> >>>>>>
> >>>>>> I could be wrong but I think the intranet is a tightly coupled  comm
> >>>>> system
> >>>>>> therefore it is secure by design.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Sun, 28 Mar 2021, 13:31 Markus KARG, 
> >>>> wrote:
> >>>>>>> We should not do any tricks or unexpected behavior but just stick
> >>>> with
> >>>>>>> SemVer.
> >>>>>>> If there is a need for a security fix, it has to be 3.6.4 and BTW
> >>>> there
> >>>>>>> should be an option to still use unsecure http as many people run
> >>>> http
> >>>>> in
> >>>>>>> their LANs.
> >>>>>>> If it contains backwards-compatible features, it has to be 3.7.0.
> >>>>>>> If it breaks backwards-compatibility, it has to be 4.0.0.
> >>>>>>> In no case it can be 3.8.0.
> >>>>>>> If mvnw was proposed for 3.7 but is not here now, then we either
> >>>> have
> >>>>> to
> >>>>>>> wait with 3.7.0, or we have to tell people that 

Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

[Jesper Udby]

@Romain: no not really. I'd hate to be in that situation where an 
"innocent" 3.6.3->3.6.4 upgrade failed and I'd had to go into more 
details about why. I've been to one of these orgs where I was doing 
architecture, data modelling, solution development and devops (as a 
one-man army) where unexpected surprises were not welcome.


Brgds

Jesper Udby

On 29/03/2021 09.37, Romain Manni-Bucau wrote:

@Jesper: just to refine, it is just a matter of adding a custom
settings.xml for the build/on the CLI (or override it in maven depending
what the org wants) to enable back http so you still don't have to set SSL
on nexus. Does it change your answer since the first point becomes no more
fully accurate with that fact?

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>


Le lun. 29 mars 2021 à 09:23, Som Lima  a écrit :


Any way thanks for the cli API

On Mon, 29 Mar 2021, 08:18 Som Lima,  wrote:


When you put a url in a browser and hit enter.

IF the url has to travel to a server on the intranet then an algorithm
ensuring tight coupling will be executed.

IF the url has to travel on the internet to get to a server then a
completely different algorithm gets executed.

The WAN algorithm relies on CHECKSUM  to ensure data integrity.
It is weak and prone to easy vulnerability.  At the very minimum the user
needs to implement encryption (HTTPS).


The LAN  algorithm  is quite different,
there is far more network traffic between two parties to ensure strong
secure connection.

API developers  and application developers  do not have access to this
layer. It is transparent.








On Mon, 29 Mar 2021, 08:03 Romain Manni-Bucau, 
wrote:


Hi,

I kind of agree intranet is as secure as the internet (ie a lot of

attacks

done last years were done on intranets). yes you are in a local vpc not
accessible from the outside but it is also where hackers try to enter
first
since then it is open bar for them.
That said it is very common to use http as a quick serving too -

thinking

to trainings and hacking sessions where a tomcat serves a local m2 for
example.
I guess this all lead to the fact we need to support HTTP anyway and
enable/document how to still use it in the coming version (and not

prevent

it in a hardcoded fashion).
In terms of security it would be left to the user to enable it

explicitly

-
defaults being secured, exactly as the 0-day vulnerability got fixed in
all
softwares.
Sounds more than relevant to me to enable that case while it is not the
default.

That said, having this kind of toggle pushes to 3.6.4 more than all

others

by design then, no?

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


Le lun. 29 mars 2021 à 08:51, Som Lima  a

écrit

:


I thought we were talking about computer programming algorithms.


Social engineering  is outside the scope of the  discussion on the

subject

of the  algorithm devised in the invisible ( to API developers),

network

layer implementation.

The  scope of discussion is that the intranet is a tightly coupled

comm

system therefore secure by design.
Imagine a couple holding each other tightly so no intruder, (third

party)

can  come in  between and interfere.


Meanwhile the internet  (loosely coupled) due to physical limitations

could

not be implemented  using the same algorithm.
It was left to users  to work out the security which can be done using
encryption (HTTPS) as one means of security. Other strategies are also
available. Only the CHECKSUM was supplied as means of data integrity

by

the

network Gods.

Anybody want to talk about intraprocess (tight coupling) and

Interprocess

(loose coupling) ?





On Sun, 28 Mar 2021, 15:39 Markus KARG, 

wrote:

Nonsense. It is common sense that most criminal acts are spawned

from

within the local network, due to social engineering.
-Markus


-Ursprüngliche Nachricht-
Von: Som Lima [mailto:somplastic...@gmail.com]
Gesendet: Sonntag, 28. März 2021 15:06
An: Maven Developers List
Betreff: Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or

other

BTW there should be an option to still use unsecure http as many

people

run http in their LANs.

I could be wrong but I think the intranet is a tightly coupled  comm

system

therefore it is secure by design.



On Sun, 28 Mar 2021, 13:31 Markus KARG, 

wrote:

We should not do any tricks or unexpected be

Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

[Romain Manni-Bucau]

@Jesper: just to refine, it is just a matter of adding a custom
settings.xml for the build/on the CLI (or override it in maven depending
what the org wants) to enable back http so you still don't have to set SSL
on nexus. Does it change your answer since the first point becomes no more
fully accurate with that fact?

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>


Le lun. 29 mars 2021 à 09:23, Som Lima  a écrit :

> Any way thanks for the cli API
>
> On Mon, 29 Mar 2021, 08:18 Som Lima,  wrote:
>
> > When you put a url in a browser and hit enter.
> >
> > IF the url has to travel to a server on the intranet then an algorithm
> > ensuring tight coupling will be executed.
> >
> > IF the url has to travel on the internet to get to a server then a
> > completely different algorithm gets executed.
> >
> > The WAN algorithm relies on CHECKSUM  to ensure data integrity.
> > It is weak and prone to easy vulnerability.  At the very minimum the user
> > needs to implement encryption (HTTPS).
> >
> >
> > The LAN  algorithm  is quite different,
> > there is far more network traffic between two parties to ensure strong
> > secure connection.
> >
> > API developers  and application developers  do not have access to this
> > layer. It is transparent.
> >
> >
> >
> >
> >
> >
> >
> >
> > On Mon, 29 Mar 2021, 08:03 Romain Manni-Bucau, 
> > wrote:
> >
> >> Hi,
> >>
> >> I kind of agree intranet is as secure as the internet (ie a lot of
> attacks
> >> done last years were done on intranets). yes you are in a local vpc not
> >> accessible from the outside but it is also where hackers try to enter
> >> first
> >> since then it is open bar for them.
> >> That said it is very common to use http as a quick serving too -
> thinking
> >> to trainings and hacking sessions where a tomcat serves a local m2 for
> >> example.
> >> I guess this all lead to the fact we need to support HTTP anyway and
> >> enable/document how to still use it in the coming version (and not
> prevent
> >> it in a hardcoded fashion).
> >> In terms of security it would be left to the user to enable it
> explicitly
> >> -
> >> defaults being secured, exactly as the 0-day vulnerability got fixed in
> >> all
> >> softwares.
> >> Sounds more than relevant to me to enable that case while it is not the
> >> default.
> >>
> >> That said, having this kind of toggle pushes to 3.6.4 more than all
> others
> >> by design then, no?
> >>
> >> 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
> >> >
> >>
> >>
> >> Le lun. 29 mars 2021 à 08:51, Som Lima  a
> écrit
> >> :
> >>
> >> > I thought we were talking about computer programming algorithms.
> >> >
> >> >
> >> > Social engineering  is outside the scope of the  discussion on the
> >> subject
> >> > of the  algorithm devised in the invisible ( to API developers),
> network
> >> > layer implementation.
> >> >
> >> > The  scope of discussion is that the intranet is a tightly coupled
> comm
> >> > system therefore secure by design.
> >> > Imagine a couple holding each other tightly so no intruder, (third
> >> party)
> >> > can  come in  between and interfere.
> >> >
> >> >
> >> > Meanwhile the internet  (loosely coupled) due to physical limitations
> >> could
> >> > not be implemented  using the same algorithm.
> >> > It was left to users  to work out the security which can be done using
> >> > encryption (HTTPS) as one means of security. Other strategies are also
> >> > available. Only the CHECKSUM was supplied as means of data integrity
> by
> &

Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

[Som Lima]

Any way thanks for the cli API

On Mon, 29 Mar 2021, 08:18 Som Lima,  wrote:

> When you put a url in a browser and hit enter.
>
> IF the url has to travel to a server on the intranet then an algorithm
> ensuring tight coupling will be executed.
>
> IF the url has to travel on the internet to get to a server then a
> completely different algorithm gets executed.
>
> The WAN algorithm relies on CHECKSUM  to ensure data integrity.
> It is weak and prone to easy vulnerability.  At the very minimum the user
> needs to implement encryption (HTTPS).
>
>
> The LAN  algorithm  is quite different,
> there is far more network traffic between two parties to ensure strong
> secure connection.
>
> API developers  and application developers  do not have access to this
> layer. It is transparent.
>
>
>
>
>
>
>
>
> On Mon, 29 Mar 2021, 08:03 Romain Manni-Bucau, 
> wrote:
>
>> Hi,
>>
>> I kind of agree intranet is as secure as the internet (ie a lot of attacks
>> done last years were done on intranets). yes you are in a local vpc not
>> accessible from the outside but it is also where hackers try to enter
>> first
>> since then it is open bar for them.
>> That said it is very common to use http as a quick serving too - thinking
>> to trainings and hacking sessions where a tomcat serves a local m2 for
>> example.
>> I guess this all lead to the fact we need to support HTTP anyway and
>> enable/document how to still use it in the coming version (and not prevent
>> it in a hardcoded fashion).
>> In terms of security it would be left to the user to enable it explicitly
>> -
>> defaults being secured, exactly as the 0-day vulnerability got fixed in
>> all
>> softwares.
>> Sounds more than relevant to me to enable that case while it is not the
>> default.
>>
>> That said, having this kind of toggle pushes to 3.6.4 more than all others
>> by design then, no?
>>
>> 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
>> >
>>
>>
>> Le lun. 29 mars 2021 à 08:51, Som Lima  a écrit
>> :
>>
>> > I thought we were talking about computer programming algorithms.
>> >
>> >
>> > Social engineering  is outside the scope of the  discussion on the
>> subject
>> > of the  algorithm devised in the invisible ( to API developers), network
>> > layer implementation.
>> >
>> > The  scope of discussion is that the intranet is a tightly coupled comm
>> > system therefore secure by design.
>> > Imagine a couple holding each other tightly so no intruder, (third
>> party)
>> > can  come in  between and interfere.
>> >
>> >
>> > Meanwhile the internet  (loosely coupled) due to physical limitations
>> could
>> > not be implemented  using the same algorithm.
>> > It was left to users  to work out the security which can be done using
>> > encryption (HTTPS) as one means of security. Other strategies are also
>> > available. Only the CHECKSUM was supplied as means of data integrity by
>> the
>> > network Gods.
>> >
>> > Anybody want to talk about intraprocess (tight coupling) and
>> Interprocess
>> > (loose coupling) ?
>> >
>> >
>> >
>> >
>> >
>> > On Sun, 28 Mar 2021, 15:39 Markus KARG,  wrote:
>> >
>> > > Nonsense. It is common sense that most criminal acts are spawned from
>> > > within the local network, due to social engineering.
>> > > -Markus
>> > >
>> > >
>> > > -Ursprüngliche Nachricht-
>> > > Von: Som Lima [mailto:somplastic...@gmail.com]
>> > > Gesendet: Sonntag, 28. März 2021 15:06
>> > > An: Maven Developers List
>> > > Betreff: Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or
>> other
>> > >
>> > > > BTW there should be an option to still use unsecure http as many
>> people
>> > > run http in their LANs.
>> > >
>> > > I could be wrong but I think the intranet is a tightly coupled  comm
>> > system
>> > > therefore it is secure by design.
>> > >
>> 

Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

[Som Lima]

When you put a url in a browser and hit enter.

IF the url has to travel to a server on the intranet then an algorithm
ensuring tight coupling will be executed.

IF the url has to travel on the internet to get to a server then a
completely different algorithm gets executed.

The WAN algorithm relies on CHECKSUM  to ensure data integrity.
It is weak and prone to easy vulnerability.  At the very minimum the user
needs to implement encryption (HTTPS).


The LAN  algorithm  is quite different,
there is far more network traffic between two parties to ensure strong
secure connection.

API developers  and application developers  do not have access to this
layer. It is transparent.








On Mon, 29 Mar 2021, 08:03 Romain Manni-Bucau, 
wrote:

> Hi,
>
> I kind of agree intranet is as secure as the internet (ie a lot of attacks
> done last years were done on intranets). yes you are in a local vpc not
> accessible from the outside but it is also where hackers try to enter first
> since then it is open bar for them.
> That said it is very common to use http as a quick serving too - thinking
> to trainings and hacking sessions where a tomcat serves a local m2 for
> example.
> I guess this all lead to the fact we need to support HTTP anyway and
> enable/document how to still use it in the coming version (and not prevent
> it in a hardcoded fashion).
> In terms of security it would be left to the user to enable it explicitly -
> defaults being secured, exactly as the 0-day vulnerability got fixed in all
> softwares.
> Sounds more than relevant to me to enable that case while it is not the
> default.
>
> That said, having this kind of toggle pushes to 3.6.4 more than all others
> by design then, no?
>
> 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
> >
>
>
> Le lun. 29 mars 2021 à 08:51, Som Lima  a écrit :
>
> > I thought we were talking about computer programming algorithms.
> >
> >
> > Social engineering  is outside the scope of the  discussion on the
> subject
> > of the  algorithm devised in the invisible ( to API developers), network
> > layer implementation.
> >
> > The  scope of discussion is that the intranet is a tightly coupled comm
> > system therefore secure by design.
> > Imagine a couple holding each other tightly so no intruder, (third party)
> > can  come in  between and interfere.
> >
> >
> > Meanwhile the internet  (loosely coupled) due to physical limitations
> could
> > not be implemented  using the same algorithm.
> > It was left to users  to work out the security which can be done using
> > encryption (HTTPS) as one means of security. Other strategies are also
> > available. Only the CHECKSUM was supplied as means of data integrity by
> the
> > network Gods.
> >
> > Anybody want to talk about intraprocess (tight coupling) and Interprocess
> > (loose coupling) ?
> >
> >
> >
> >
> >
> > On Sun, 28 Mar 2021, 15:39 Markus KARG,  wrote:
> >
> > > Nonsense. It is common sense that most criminal acts are spawned from
> > > within the local network, due to social engineering.
> > > -Markus
> > >
> > >
> > > -Ursprüngliche Nachricht-
> > > Von: Som Lima [mailto:somplastic...@gmail.com]
> > > Gesendet: Sonntag, 28. März 2021 15:06
> > > An: Maven Developers List
> > > Betreff: Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or
> other
> > >
> > > > BTW there should be an option to still use unsecure http as many
> people
> > > run http in their LANs.
> > >
> > > I could be wrong but I think the intranet is a tightly coupled  comm
> > system
> > > therefore it is secure by design.
> > >
> > >
> > >
> > > On Sun, 28 Mar 2021, 13:31 Markus KARG, 
> wrote:
> > >
> > > > We should not do any tricks or unexpected behavior but just stick
> with
> > > > SemVer.
> > > > If there is a need for a security fix, it has to be 3.6.4 and BTW
> there
> > > > should be an option to still use unsecure http as many people run
> http
> > in
> > > > their LANs.
> > > > If it contains backwards-compatible features, it has to be 3.7.0.
> > > > If it breaks backwards-compatibility, it has to be 4.0.

Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

[Jesper Udby]

Hi,

I'd like to give my input too.

3.6.4 is IMHO not an option since there is change of behavior that would 
come as a surprise for some. I know of smaller organisations where 
running nexus, jenkins etc on HTTP is fine and switching to SSL is not 
trivial since they do not have proper DevOps or certificate management 
in place.


3.7.0 is controversial since it would not contain "advertised features".

3.8.0+ is better, even if it will cause some surprises for people who'd 
believe that features not delivered in 3.7 would then at least be 
available in 3.8...


And I think we should always be pragmatic. Semver is a scheme that can 
be interpreted/implemented in different ways. I don't see skipping a 
number as a big deal.


Best regards

Jesper Udby

On 29/03/2021 09.03, Romain Manni-Bucau wrote:

Hi,

I kind of agree intranet is as secure as the internet (ie a lot of attacks
done last years were done on intranets). yes you are in a local vpc not
accessible from the outside but it is also where hackers try to enter first
since then it is open bar for them.
That said it is very common to use http as a quick serving too - thinking
to trainings and hacking sessions where a tomcat serves a local m2 for
example.
I guess this all lead to the fact we need to support HTTP anyway and
enable/document how to still use it in the coming version (and not prevent
it in a hardcoded fashion).
In terms of security it would be left to the user to enable it explicitly -
defaults being secured, exactly as the 0-day vulnerability got fixed in all
softwares.
Sounds more than relevant to me to enable that case while it is not the
default.

That said, having this kind of toggle pushes to 3.6.4 more than all others
by design then, no?

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>


Le lun. 29 mars 2021 à 08:51, Som Lima  a écrit :


I thought we were talking about computer programming algorithms.


Social engineering  is outside the scope of the  discussion on the subject
of the  algorithm devised in the invisible ( to API developers), network
layer implementation.

The  scope of discussion is that the intranet is a tightly coupled comm
system therefore secure by design.
Imagine a couple holding each other tightly so no intruder, (third party)
can  come in  between and interfere.


Meanwhile the internet  (loosely coupled) due to physical limitations could
not be implemented  using the same algorithm.
It was left to users  to work out the security which can be done using
encryption (HTTPS) as one means of security. Other strategies are also
available. Only the CHECKSUM was supplied as means of data integrity by the
network Gods.

Anybody want to talk about intraprocess (tight coupling) and Interprocess
(loose coupling) ?





On Sun, 28 Mar 2021, 15:39 Markus KARG,  wrote:


Nonsense. It is common sense that most criminal acts are spawned from
within the local network, due to social engineering.
-Markus


-Ursprüngliche Nachricht-
Von: Som Lima [mailto:somplastic...@gmail.com]
Gesendet: Sonntag, 28. März 2021 15:06
An: Maven Developers List
Betreff: Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other


BTW there should be an option to still use unsecure http as many people

run http in their LANs.

I could be wrong but I think the intranet is a tightly coupled  comm

system

therefore it is secure by design.



On Sun, 28 Mar 2021, 13:31 Markus KARG,  wrote:


We should not do any tricks or unexpected behavior but just stick with
SemVer.
If there is a need for a security fix, it has to be 3.6.4 and BTW there
should be an option to still use unsecure http as many people run http

in

their LANs.
If it contains backwards-compatible features, it has to be 3.7.0.
If it breaks backwards-compatibility, it has to be 4.0.0.
In no case it can be 3.8.0.
If mvnw was proposed for 3.7 but is not here now, then we either have

to

wait with 3.7.0, or we have to tell people that we move mvnw to 3.8 or

4.0.

I do not see a need for any discussion at all, as SemVer is pretty

clear

about the sole correct answer.
-Markus

-Ursprüngliche Nachricht-
Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
Gesendet: Sonntag, 28. März 2021 11:47
An: Maven Developers List
Betreff: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

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 chan

Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

[Romain Manni-Bucau]

Hi,

I kind of agree intranet is as secure as the internet (ie a lot of attacks
done last years were done on intranets). yes you are in a local vpc not
accessible from the outside but it is also where hackers try to enter first
since then it is open bar for them.
That said it is very common to use http as a quick serving too - thinking
to trainings and hacking sessions where a tomcat serves a local m2 for
example.
I guess this all lead to the fact we need to support HTTP anyway and
enable/document how to still use it in the coming version (and not prevent
it in a hardcoded fashion).
In terms of security it would be left to the user to enable it explicitly -
defaults being secured, exactly as the 0-day vulnerability got fixed in all
softwares.
Sounds more than relevant to me to enable that case while it is not the
default.

That said, having this kind of toggle pushes to 3.6.4 more than all others
by design then, no?

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>


Le lun. 29 mars 2021 à 08:51, Som Lima  a écrit :

> I thought we were talking about computer programming algorithms.
>
>
> Social engineering  is outside the scope of the  discussion on the subject
> of the  algorithm devised in the invisible ( to API developers), network
> layer implementation.
>
> The  scope of discussion is that the intranet is a tightly coupled comm
> system therefore secure by design.
> Imagine a couple holding each other tightly so no intruder, (third party)
> can  come in  between and interfere.
>
>
> Meanwhile the internet  (loosely coupled) due to physical limitations could
> not be implemented  using the same algorithm.
> It was left to users  to work out the security which can be done using
> encryption (HTTPS) as one means of security. Other strategies are also
> available. Only the CHECKSUM was supplied as means of data integrity by the
> network Gods.
>
> Anybody want to talk about intraprocess (tight coupling) and Interprocess
> (loose coupling) ?
>
>
>
>
>
> On Sun, 28 Mar 2021, 15:39 Markus KARG,  wrote:
>
> > Nonsense. It is common sense that most criminal acts are spawned from
> > within the local network, due to social engineering.
> > -Markus
> >
> >
> > -Ursprüngliche Nachricht-----
> > Von: Som Lima [mailto:somplastic...@gmail.com]
> > Gesendet: Sonntag, 28. März 2021 15:06
> > An: Maven Developers List
> > Betreff: Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other
> >
> > > BTW there should be an option to still use unsecure http as many people
> > run http in their LANs.
> >
> > I could be wrong but I think the intranet is a tightly coupled  comm
> system
> > therefore it is secure by design.
> >
> >
> >
> > On Sun, 28 Mar 2021, 13:31 Markus KARG,  wrote:
> >
> > > We should not do any tricks or unexpected behavior but just stick with
> > > SemVer.
> > > If there is a need for a security fix, it has to be 3.6.4 and BTW there
> > > should be an option to still use unsecure http as many people run http
> in
> > > their LANs.
> > > If it contains backwards-compatible features, it has to be 3.7.0.
> > > If it breaks backwards-compatibility, it has to be 4.0.0.
> > > In no case it can be 3.8.0.
> > > If mvnw was proposed for 3.7 but is not here now, then we either have
> to
> > > wait with 3.7.0, or we have to tell people that we move mvnw to 3.8 or
> > 4.0.
> > > I do not see a need for any discussion at all, as SemVer is pretty
> clear
> > > about the sole correct answer.
> > > -Markus
> > >
> > > -Ursprüngliche Nachricht-
> > > Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
> > > Gesendet: Sonntag, 28. März 2021 11:47
> > > An: Maven Developers List
> > > Betreff: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other
> > >
> > > 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
> > >

Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

[Som Lima]

I thought we were talking about computer programming algorithms.


Social engineering  is outside the scope of the  discussion on the subject
of the  algorithm devised in the invisible ( to API developers), network
layer implementation.

The  scope of discussion is that the intranet is a tightly coupled comm
system therefore secure by design.
Imagine a couple holding each other tightly so no intruder, (third party)
can  come in  between and interfere.


Meanwhile the internet  (loosely coupled) due to physical limitations could
not be implemented  using the same algorithm.
It was left to users  to work out the security which can be done using
encryption (HTTPS) as one means of security. Other strategies are also
available. Only the CHECKSUM was supplied as means of data integrity by the
network Gods.

Anybody want to talk about intraprocess (tight coupling) and Interprocess
(loose coupling) ?





On Sun, 28 Mar 2021, 15:39 Markus KARG,  wrote:

> Nonsense. It is common sense that most criminal acts are spawned from
> within the local network, due to social engineering.
> -Markus
>
>
> -Ursprüngliche Nachricht-
> Von: Som Lima [mailto:somplastic...@gmail.com]
> Gesendet: Sonntag, 28. März 2021 15:06
> An: Maven Developers List
> Betreff: Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other
>
> > BTW there should be an option to still use unsecure http as many people
> run http in their LANs.
>
> I could be wrong but I think the intranet is a tightly coupled  comm system
> therefore it is secure by design.
>
>
>
> On Sun, 28 Mar 2021, 13:31 Markus KARG,  wrote:
>
> > We should not do any tricks or unexpected behavior but just stick with
> > SemVer.
> > If there is a need for a security fix, it has to be 3.6.4 and BTW there
> > should be an option to still use unsecure http as many people run http in
> > their LANs.
> > If it contains backwards-compatible features, it has to be 3.7.0.
> > If it breaks backwards-compatibility, it has to be 4.0.0.
> > In no case it can be 3.8.0.
> > If mvnw was proposed for 3.7 but is not here now, then we either have to
> > wait with 3.7.0, or we have to tell people that we move mvnw to 3.8 or
> 4.0.
> > I do not see a need for any discussion at all, as SemVer is pretty clear
> > about the sole correct answer.
> > -Markus
> >
> > -Ursprüngliche Nachricht-----
> > Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
> > Gesendet: Sonntag, 28. März 2021 11:47
> > An: Maven Developers List
> > Betreff: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other
> >
> > 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 

Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

[Gary Gregory]

In my mind, this is simple: features go into major and minor versions,
maintenance versions are only for bugs, therefore a feature change is not
done in a maintenance version.

Gary

On Sun, Mar 28, 2021, 05:47 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
> >
>

Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

[Romain Manni-Bucau]

So seems there are two points to refine:

1. Is the http change *without as such toggle* a security fix (3.6) or
feature (3.7 or 3.8)
2. Do we fully reject semver and use 2 digit versioning (seems it is what
we often do).

On 1 im clearly for the security fix.
On 2 i dont care but we should explicit it for users to let them write
relevant versioning policies (use 3.N vs use 3.6.N for ex). Trust me, it
costs a lot for nothing to integrators/users and long term projects.

Le dim. 28 mars 2021 à 16:39, Markus KARG  a écrit :

> Nonsense. It is common sense that most criminal acts are spawned from
> within the local network, due to social engineering.
> -Markus
>
>
> -Ursprüngliche Nachricht-
> Von: Som Lima [mailto:somplastic...@gmail.com]
> Gesendet: Sonntag, 28. März 2021 15:06
> An: Maven Developers List
> Betreff: Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other
>
> > BTW there should be an option to still use unsecure http as many people
> run http in their LANs.
>
> I could be wrong but I think the intranet is a tightly coupled  comm system
> therefore it is secure by design.
>
>
>
> On Sun, 28 Mar 2021, 13:31 Markus KARG,  wrote:
>
> > We should not do any tricks or unexpected behavior but just stick with
> > SemVer.
> > If there is a need for a security fix, it has to be 3.6.4 and BTW there
> > should be an option to still use unsecure http as many people run http in
> > their LANs.
> > If it contains backwards-compatible features, it has to be 3.7.0.
> > If it breaks backwards-compatibility, it has to be 4.0.0.
> > In no case it can be 3.8.0.
> > If mvnw was proposed for 3.7 but is not here now, then we either have to
> > wait with 3.7.0, or we have to tell people that we move mvnw to 3.8 or
> 4.0.
> > I do not see a need for any discussion at all, as SemVer is pretty clear
> > about the sole correct answer.
> > -Markus
> >
> > -Ursprüngliche Nachricht-----
> > Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
> > Gesendet: Sonntag, 28. März 2021 11:47
> > An: Maven Developers List
> > Betreff: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other
> >
> > 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,
> &

AW: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

[Markus KARG]

Nonsense. It is common sense that most criminal acts are spawned from within 
the local network, due to social engineering.
-Markus


-Ursprüngliche Nachricht-
Von: Som Lima [mailto:somplastic...@gmail.com] 
Gesendet: Sonntag, 28. März 2021 15:06
An: Maven Developers List
Betreff: Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

> BTW there should be an option to still use unsecure http as many people
run http in their LANs.

I could be wrong but I think the intranet is a tightly coupled  comm system
therefore it is secure by design.



On Sun, 28 Mar 2021, 13:31 Markus KARG,  wrote:

> We should not do any tricks or unexpected behavior but just stick with
> SemVer.
> If there is a need for a security fix, it has to be 3.6.4 and BTW there
> should be an option to still use unsecure http as many people run http in
> their LANs.
> If it contains backwards-compatible features, it has to be 3.7.0.
> If it breaks backwards-compatibility, it has to be 4.0.0.
> In no case it can be 3.8.0.
> If mvnw was proposed for 3.7 but is not here now, then we either have to
> wait with 3.7.0, or we have to tell people that we move mvnw to 3.8 or 4.0.
> I do not see a need for any discussion at all, as SemVer is pretty clear
> about the sole correct answer.
> -Markus
>
> -Ursprüngliche Nachricht-
> Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
> Gesendet: Sonntag, 28. März 2021 11:47
> An: Maven Developers List
> Betreff: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other
>
> 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
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

[Stephen Connolly]

3.8.1 as we already burned and accidentally released 3.8.0

Though if we could go back in time to before the vote was started, it
should have been 3.6.4 IMO... but since the release manager went with
3.8.0, that’s the train we’re on

FTR the release manager’s decision on version number has always been final
in my mind (obviously consulting the community is better for fostering the
community, but in my book the version number is not for voting... the
release manager picks the number and then the vote is called)

On Sun 28 Mar 2021 at 10:47, 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
> >
>
-- 
Sent from my phone

Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

[Som Lima]

> BTW there should be an option to still use unsecure http as many people
run http in their LANs.

I could be wrong but I think the intranet is a tightly coupled  comm system
therefore it is secure by design.



On Sun, 28 Mar 2021, 13:31 Markus KARG,  wrote:

> We should not do any tricks or unexpected behavior but just stick with
> SemVer.
> If there is a need for a security fix, it has to be 3.6.4 and BTW there
> should be an option to still use unsecure http as many people run http in
> their LANs.
> If it contains backwards-compatible features, it has to be 3.7.0.
> If it breaks backwards-compatibility, it has to be 4.0.0.
> In no case it can be 3.8.0.
> If mvnw was proposed for 3.7 but is not here now, then we either have to
> wait with 3.7.0, or we have to tell people that we move mvnw to 3.8 or 4.0.
> I do not see a need for any discussion at all, as SemVer is pretty clear
> about the sole correct answer.
> -Markus
>
> -Ursprüngliche Nachricht-
> Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
> Gesendet: Sonntag, 28. März 2021 11:47
> An: Maven Developers List
> Betreff: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other
>
> 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
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

AW: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

[Markus KARG]

>> - Why not 3.7.0?
>> Apache Maven 3.7.0 has been advertised in the past that it would be the
>> first release where you could optionally activate the build/consumer
>> feature: the version containing this feature has been renamed to 4.0.0.
>> Reusing 3.7.0 might lead to confusion, hence we picked the next available
>> minor version.
> But we will deliver 3.8.xxx with no 3.7.xx which should have the
> “advertised” feature.
> Sorry following this reasoning it feels even worst and potentially more
> confusing for users.

I second that. If a feature was proposed for 3.7 and a user downloads 3.8 he 
simply thinks he missed 3.7 and will definitiely expect the feature to exist.

-Markus




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

AW: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

[Markus KARG]

We should not do any tricks or unexpected behavior but just stick with SemVer.
If there is a need for a security fix, it has to be 3.6.4 and BTW there should 
be an option to still use unsecure http as many people run http in their LANs.
If it contains backwards-compatible features, it has to be 3.7.0.
If it breaks backwards-compatibility, it has to be 4.0.0.
In no case it can be 3.8.0.
If mvnw was proposed for 3.7 but is not here now, then we either have to wait 
with 3.7.0, or we have to tell people that we move mvnw to 3.8 or 4.0.
I do not see a need for any discussion at all, as SemVer is pretty clear about 
the sole correct answer.
-Markus

-Ursprüngliche Nachricht-
Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com] 
Gesendet: Sonntag, 28. März 2021 11:47
An: Maven Developers List
Betreff: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

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>


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

[Michael Osipov]

Am 2021-03-28 um 11:47 schrieb Romain Manni-Bucau:

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)?


I follow here Hervè's explanation. This is a behavior change, not just 
some security fix which isn't noticed at best. It cannot be a patch 
version. Moreover, it uses a new minor of Maven Resolver which have 
behavioral changes as well. This must ship as 3.x.
3.7.x does not qualify because that version has been already canceled 
during development. It would be just inconsistent to reuse it.


At the end, Hervé, Robert and me spend too much time in discussing, 
reviewing and testing of the change that I want to get over with and go 
on with Maven 4.


Personally, I do not absolute care about Maven Wrapper. It is a feature, 
not a fix or a behavioral change people can live without.


Sum up: It has to be 3.8.x or bust.


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

[Olivier Lamy]

On Sun, 28 Mar 2021 at 8:07 pm, Hervé BOUTEMY  wrote:

> thank you Romain for your view
>
> current reasoning behind 3.8.0 choice is written in release notes [1]
>
> -  Why not 3.6.4?
> This is not just a bugfix as it contains three features that cause a
> change of default behavior (external HTTP insecure URLs are now blocked by
> default): your builds may fail when using this new Maven release, if you
> use now blocked repositories. Please check and eventually fix before
> upgrading.
>
> - Why not 3.7.0?
> Apache Maven 3.7.0 has been advertised in the past that it would be the
> first release where you could optionally activate the build/consumer
> feature: the version containing this feature has been renamed to 4.0.0.
> Reusing 3.7.0 might lead to confusion, hence we picked the next available
> minor version.



But we will deliver 3.8.xxx with no 3.7.xx which should have the
“advertised” feature.
Sorry following this reasoning it feels even worst and potentially more
confusing for users.
Btw seriously “advertise” who really remember this... I don’t really
remember official “advertisement” from the Apache Maven project itself.


> I personally have a strong feeling against 3.6.4: it's not just a bugfix,
> it would cause surprises to users upgrading with full confidence.
>
> On 3.7 vs 3.8, reasoning is fully written. We skipped versions in the
> past, it's not a big deal.
>
> tm me, 3.8.0 is the best choice for users (and if they have questions why
> this version, they have 2 little answers in the release notes)
>
> Regards,
>
> Hervé
>
>
> [1]
> https://maven.apache.org/docs/3.8.0/release-notes.html#why-does-this-version-have-the-value-3-8-0
>
> Le dimanche 28 mars 2021, 11:47:11 CEST Romain Manni-Bucau a écrit :
> > 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
> > >
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

[Som Lima]

Thanks for  clearing that up.
One step closer to choosing
the version number.



On Sun, 28 Mar 2021, 12:05 Tibor Digana,  wrote:

> Hi Som Lima,
>
> Regarding (1), the Maven Central works with HTTPS for some time already.
> Regarding the Repository Managers, e.g. Nexus or JFrog they have to be
> updated to HTTPS in companies which is normal work for the administrators
> and devops teams, not for the users or devs, but nowadays the
> worldwide situation is so that security is the higher priority and it can
> be configured very easily. It;s not only Maven Central but also RedHat
> Maven Repository https://maven.repository.redhat.com/ga/ which works with
> HTTPS and I believe that many other Providers have already switched their
> repositories to HTTPS. It would be more difficult to find the opposite!
> Regarding the instructions to upgrade Nexus to HTTPS, it's quite easy, but
> as I said before, this is the task for the devops teams mostly.
> T
>
> On Sun, Mar 28, 2021 at 12:28 PM Som Lima  wrote:
>
> > As a user these points would be  MAJOR concerns
> > 1. external HTTP insecure URLs are now blocked by default
> >
> > 2. your builds may fail when using this new Maven release.
> >
> > I would say go for version 5.0 suggesting a fresh start. A clear
> > separation.
> >
> > Leaving you enough versions to fix 3.6.3 bugs where existing project are
> > still compatible.
> >
> > Just floating an indea.
> >
> >
> >
> >
> > On Sun, 28 Mar 2021, 11:07 Hervé BOUTEMY,  wrote:
> >
> > > thank you Romain for your view
> > >
> > > current reasoning behind 3.8.0 choice is written in release notes [1]
> > >
> > > -  Why not 3.6.4?
> > > This is not just a bugfix as it contains three features that cause a
> > > change of default behavior (external HTTP insecure URLs are now blocked
> > by
> > > default): your builds may fail when using this new Maven release, if
> you
> > > use now blocked repositories. Please check and eventually fix before
> > > upgrading.
> > >
> > > - Why not 3.7.0?
> > > Apache Maven 3.7.0 has been advertised in the past that it would be the
> > > first release where you could optionally activate the build/consumer
> > > feature: the version containing this feature has been renamed to 4.0.0.
> > > Reusing 3.7.0 might lead to confusion, hence we picked the next
> available
> > > minor version.
> > >
> > >
> > > I personally have a strong feeling against 3.6.4: it's not just a
> bugfix,
> > > it would cause surprises to users upgrading with full confidence.
> > >
> > > On 3.7 vs 3.8, reasoning is fully written. We skipped versions in the
> > > past, it's not a big deal.
> > >
> > > tm me, 3.8.0 is the best choice for users (and if they have questions
> why
> > > this version, they have 2 little answers in the release notes)
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > >
> > > [1]
> > >
> >
> https://maven.apache.org/docs/3.8.0/release-notes.html#why-does-this-version-have-the-value-3-8-0
> > >
> > > Le dimanche 28 mars 2021, 11:47:11 CEST Romain Manni-Bucau a écrit :
> > > > 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 

Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

[Tibor Digana]

Hi Som Lima,

Regarding (1), the Maven Central works with HTTPS for some time already.
Regarding the Repository Managers, e.g. Nexus or JFrog they have to be
updated to HTTPS in companies which is normal work for the administrators
and devops teams, not for the users or devs, but nowadays the
worldwide situation is so that security is the higher priority and it can
be configured very easily. It;s not only Maven Central but also RedHat
Maven Repository https://maven.repository.redhat.com/ga/ which works with
HTTPS and I believe that many other Providers have already switched their
repositories to HTTPS. It would be more difficult to find the opposite!
Regarding the instructions to upgrade Nexus to HTTPS, it's quite easy, but
as I said before, this is the task for the devops teams mostly.
T

On Sun, Mar 28, 2021 at 12:28 PM Som Lima  wrote:

> As a user these points would be  MAJOR concerns
> 1. external HTTP insecure URLs are now blocked by default
>
> 2. your builds may fail when using this new Maven release.
>
> I would say go for version 5.0 suggesting a fresh start. A clear
> separation.
>
> Leaving you enough versions to fix 3.6.3 bugs where existing project are
> still compatible.
>
> Just floating an indea.
>
>
>
>
> On Sun, 28 Mar 2021, 11:07 Hervé BOUTEMY,  wrote:
>
> > thank you Romain for your view
> >
> > current reasoning behind 3.8.0 choice is written in release notes [1]
> >
> > -  Why not 3.6.4?
> > This is not just a bugfix as it contains three features that cause a
> > change of default behavior (external HTTP insecure URLs are now blocked
> by
> > default): your builds may fail when using this new Maven release, if you
> > use now blocked repositories. Please check and eventually fix before
> > upgrading.
> >
> > - Why not 3.7.0?
> > Apache Maven 3.7.0 has been advertised in the past that it would be the
> > first release where you could optionally activate the build/consumer
> > feature: the version containing this feature has been renamed to 4.0.0.
> > Reusing 3.7.0 might lead to confusion, hence we picked the next available
> > minor version.
> >
> >
> > I personally have a strong feeling against 3.6.4: it's not just a bugfix,
> > it would cause surprises to users upgrading with full confidence.
> >
> > On 3.7 vs 3.8, reasoning is fully written. We skipped versions in the
> > past, it's not a big deal.
> >
> > tm me, 3.8.0 is the best choice for users (and if they have questions why
> > this version, they have 2 little answers in the release notes)
> >
> > Regards,
> >
> > Hervé
> >
> >
> > [1]
> >
> https://maven.apache.org/docs/3.8.0/release-notes.html#why-does-this-version-have-the-value-3-8-0
> >
> > Le dimanche 28 mars 2021, 11:47:11 CEST Romain Manni-Bucau a écrit :
> > > 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 

Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

[Romain Manni-Bucau]

Side note: was reviewing TomEE versioning policy which is very very close
to what we find in most companies having a versioning policy for security
vulnerabilities (https://tomee.apache.org/security/) and it tends to show
that the 3.6 handling would be a 3.6.3.1 with the security fix. Maybe an
option which explicits the security fix better (just speaking of 3.6 branch
handling, whatever is picked for the overall next release number if it is
not 3.6.4).

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le dim. 28 mars 2021 à 12:28, Som Lima  a écrit :

> As a user these points would be  MAJOR concerns
> 1. external HTTP insecure URLs are now blocked by default
>
> 2. your builds may fail when using this new Maven release.
>
> I would say go for version 5.0 suggesting a fresh start. A clear
> separation.
>
> Leaving you enough versions to fix 3.6.3 bugs where existing project are
> still compatible.
>
> Just floating an indea.
>
>
>
>
> On Sun, 28 Mar 2021, 11:07 Hervé BOUTEMY,  wrote:
>
> > thank you Romain for your view
> >
> > current reasoning behind 3.8.0 choice is written in release notes [1]
> >
> > -  Why not 3.6.4?
> > This is not just a bugfix as it contains three features that cause a
> > change of default behavior (external HTTP insecure URLs are now blocked
> by
> > default): your builds may fail when using this new Maven release, if you
> > use now blocked repositories. Please check and eventually fix before
> > upgrading.
> >
> > - Why not 3.7.0?
> > Apache Maven 3.7.0 has been advertised in the past that it would be the
> > first release where you could optionally activate the build/consumer
> > feature: the version containing this feature has been renamed to 4.0.0.
> > Reusing 3.7.0 might lead to confusion, hence we picked the next available
> > minor version.
> >
> >
> > I personally have a strong feeling against 3.6.4: it's not just a bugfix,
> > it would cause surprises to users upgrading with full confidence.
> >
> > On 3.7 vs 3.8, reasoning is fully written. We skipped versions in the
> > past, it's not a big deal.
> >
> > tm me, 3.8.0 is the best choice for users (and if they have questions why
> > this version, they have 2 little answers in the release notes)
> >
> > Regards,
> >
> > Hervé
> >
> >
> > [1]
> >
> https://maven.apache.org/docs/3.8.0/release-notes.html#why-does-this-version-have-the-value-3-8-0
> >
> > Le dimanche 28 mars 2021, 11:47:11 CEST Romain Manni-Bucau a écrit :
> > > 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 

Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

[Som Lima]

As a user these points would be  MAJOR concerns
1. external HTTP insecure URLs are now blocked by default

2. your builds may fail when using this new Maven release.

I would say go for version 5.0 suggesting a fresh start. A clear separation.

Leaving you enough versions to fix 3.6.3 bugs where existing project are
still compatible.

Just floating an indea.




On Sun, 28 Mar 2021, 11:07 Hervé BOUTEMY,  wrote:

> thank you Romain for your view
>
> current reasoning behind 3.8.0 choice is written in release notes [1]
>
> -  Why not 3.6.4?
> This is not just a bugfix as it contains three features that cause a
> change of default behavior (external HTTP insecure URLs are now blocked by
> default): your builds may fail when using this new Maven release, if you
> use now blocked repositories. Please check and eventually fix before
> upgrading.
>
> - Why not 3.7.0?
> Apache Maven 3.7.0 has been advertised in the past that it would be the
> first release where you could optionally activate the build/consumer
> feature: the version containing this feature has been renamed to 4.0.0.
> Reusing 3.7.0 might lead to confusion, hence we picked the next available
> minor version.
>
>
> I personally have a strong feeling against 3.6.4: it's not just a bugfix,
> it would cause surprises to users upgrading with full confidence.
>
> On 3.7 vs 3.8, reasoning is fully written. We skipped versions in the
> past, it's not a big deal.
>
> tm me, 3.8.0 is the best choice for users (and if they have questions why
> this version, they have 2 little answers in the release notes)
>
> Regards,
>
> Hervé
>
>
> [1]
> https://maven.apache.org/docs/3.8.0/release-notes.html#why-does-this-version-have-the-value-3-8-0
>
> Le dimanche 28 mars 2021, 11:47:11 CEST Romain Manni-Bucau a écrit :
> > 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
> > >
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

[Romain Manni-Bucau]

Hi Hervé,

What about the 3.6.4 with this fix need anyway (to be clear: security fixes
must be backported in ~LTS, ie 3.6 as of today - even if we can't have such
statement it is needed in practise anyway? I don't clearly read in your
answer what's would be the plan to manage it. To try to be very clear: 3.6
was so much spread that we can't skip the backport of security fixes for
some times in this branch so creating another branch will require more work
for us or companies forks which I'd like to avoid.

About 3.7.0: we discussed it with a scope but it is not the first time a
release would get another scope and most users didn't get this anyway from
what I saw so tempted to say 3.7 or 3.8 in that regard is the same.
Strictly speaking 3.8 is worse cause 3.7 scope will not be in 3.8 so user
will feel he missed a release with a feature so he will get way more and
actually he just gets a security fix so no feature for him, no? We already
got these negative feedbacks due to a similar choice by the past so can be
good to try to avoid them this time (and if at the end we get as much
negative feedbacks with the opposite choice then we don't care next time?).

Le dim. 28 mars 2021 à 12:07, Hervé BOUTEMY  a
écrit :

> thank you Romain for your view
>
> current reasoning behind 3.8.0 choice is written in release notes [1]
>
> -  Why not 3.6.4?
> This is not just a bugfix as it contains three features that cause a
> change of default behavior (external HTTP insecure URLs are now blocked by
> default): your builds may fail when using this new Maven release, if you
> use now blocked repositories. Please check and eventually fix before
> upgrading.
>
> - Why not 3.7.0?
> Apache Maven 3.7.0 has been advertised in the past that it would be the
> first release where you could optionally activate the build/consumer
> feature: the version containing this feature has been renamed to 4.0.0.
> Reusing 3.7.0 might lead to confusion, hence we picked the next available
> minor version.
>
>
> I personally have a strong feeling against 3.6.4: it's not just a bugfix,
> it would cause surprises to users upgrading with full confidence.
>
> On 3.7 vs 3.8, reasoning is fully written. We skipped versions in the
> past, it's not a big deal.
>
> tm me, 3.8.0 is the best choice for users (and if they have questions why
> this version, they have 2 little answers in the release notes)
>
> Regards,
>
> Hervé
>
>
> [1]
> https://maven.apache.org/docs/3.8.0/release-notes.html#why-does-this-version-have-the-value-3-8-0
>
> Le dimanche 28 mars 2021, 11:47:11 CEST Romain Manni-Bucau a écrit :
> > 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)?
> >
> 

Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

[Hervé BOUTEMY]

thank you Romain for your view

current reasoning behind 3.8.0 choice is written in release notes [1]

-  Why not 3.6.4?
This is not just a bugfix as it contains three features that cause a change of 
default behavior (external HTTP insecure URLs are now blocked by default): your 
builds may fail when using this new Maven release, if you use now blocked 
repositories. Please check and eventually fix before upgrading.

- Why not 3.7.0?
Apache Maven 3.7.0 has been advertised in the past that it would be the first 
release where you could optionally activate the build/consumer feature: the 
version containing this feature has been renamed to 4.0.0. Reusing 3.7.0 might 
lead to confusion, hence we picked the next available minor version.


I personally have a strong feeling against 3.6.4: it's not just a bugfix, it 
would cause surprises to users upgrading with full confidence.

On 3.7 vs 3.8, reasoning is fully written. We skipped versions in the past, 
it's not a big deal.

tm me, 3.8.0 is the best choice for users (and if they have questions why this 
version, they have 2 little answers in the release notes)

Regards,

Hervé


[1] 
https://maven.apache.org/docs/3.8.0/release-notes.html#why-does-this-version-have-the-value-3-8-0

Le dimanche 28 mars 2021, 11:47:11 CEST Romain Manni-Bucau a écrit :
> 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 
> | LinkedIn  | Book
>  >





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

[Romain Manni-Bucau]

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  |
LinkedIn  | Book