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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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 <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 dim. 28 mars 2021 à 12:28, Som Lima <[hidden email]> 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, <[hidden email]> 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 <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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

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, <[hidden email]> 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 <[hidden email]> 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, <[hidden email]> 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 <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: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

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

Olivier Lamy
In reply to this post by Romain Manni-Bucau
On Sun, 28 Mar 2021 at 8:07 pm, Hervé BOUTEMY <[hidden email]> 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 <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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> --
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy
Reply | Threaded
Open this post in threaded view
|

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

Jesper Udby
In reply to this post by Romain Manni-Bucau
@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 <[hidden email]> a écrit :
>
>> Any way thanks for the cli API
>>
>> On Mon, 29 Mar 2021, 08:18 Som Lima, <[hidden email]> 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, <[hidden email]>
>>> 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 <[hidden email]> 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, <[hidden email]>
>> 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:[hidden email]]
>>>>>> 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, <[hidden email]>
>>>> 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:[hidden email]]
>>>>>>> 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: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Jesper Udby
I think removing the "suprise" part of a minor upgrade would be a good
compromise :-)

Brgds

Jesper Udby

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

> Le lun. 29 mars 2021 à 10:24, Jesper Udby <[hidden email]> a écrit :
>
>> @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.
>>
> I hear that but I fail to see how 3.x x > 6 solves that.
> In all cases you will go that way - or not upgrade which is not a topic for
> that thread - and since 3.x will be advertised as fixing a security issue
> it wil be required anyway to go that way, no?
>
> So, at the moment, I only see people as being forced to backport the fix
> and configuration in all their settings to be able to pass security
> validations/certifications/... and still use the 3.6 to respect their
> versioning constraint.
>
> Would doing a 3.6.4 without the default config but the fix (which means it
> can be enabled but does not break OOTB) and a 3.7 (or whatever) with the
> config added in *by default* would be saner for everyone?
> Sounds like a good compromise for everyone, no?
>
>
>> 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 <[hidden email]> a
>> écrit :
>>>> Any way thanks for the cli API
>>>>
>>>> On Mon, 29 Mar 2021, 08:18 Som Lima, <[hidden email]> 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, <[hidden email]>
>>>>> 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 <[hidden email]> 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, <[hidden email]>
>>>> 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:[hidden email]]
>>>>>>>> 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, <[hidden email]>
>>>>>> 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:[hidden email]]
>>>>>>>>> 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: [hidden email]
>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>
>>>>>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Arnaud Héritier
In reply to this post by Romain Manni-Bucau
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 <[hidden email]>
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 <[hidden email]> wrote:
> > Hi all,>
> >
> > Before we reroll the failed 3.8.0 I'd like we discuss openly the next>
> > versioning since it seems we didn't reach a consensus yet and trying to
> not>
> > create too much friction for users and in the community.>
> >
> > As a reminder the only feature the release will get is to prevent HTTP
> repo>
> > (in favor of HTTPS ones). In that regard it is a breaking change if
> users>
> > rely on HTTP repo but a security fix (I don't come back on the HTTP ->>
> > HTTPS move IT ecosystem got recently here).>
> >
> > So it seems there are multiple versioning options:>
> >
> > 1. 3.6.4: seems natural since it is a security fix, enables companies to>
> > get this fix respecting a project versioning policy without having to>
> > upgrade and avoids us to have to maintain 3.6 + 3.7/3.8 and soon 4.x.>
> > Indeed it requires a very well documented paragraph about this change
> and>
> > how to workaround it (local proxy/mirror is a trivial one for example)
> but>
> > it will be the case whatever version we pick anyway IMHO.>
> > 2. 3.7.0: since it is a breaking change it can seem natural too (but has>
> > the pitfall to likely require a backport in 3.6 anyway, due to the>
> > versioning policies which can prevent some users to upgrade to a 3.7)>
> > 3. 3.8.0: was the vote, seems the rational was that originally we>
> > targetting mvnw in 3.7 and since we didn't make it 3.8 was used. Have to>
> > admit I'm not sure of this reasoning more than that (cause for me if we>
> > don't have a planned feature we can either try to push/wait for it or>
> > postpone it but not skip a version due to that) so if anyone wants to>
> > complete the reasoning here it would be great.>
> >
> > Indeed my preference is for 3.6.4 which has the most advantages for>
> > everyone and no additional drawbacks compared to 3.7 or 3.8 options
> until>
> > we try to push to get mvnw in which would mean 3.7 becomes more natural>
> > (and likely imply a 3.6.x maintenance version).>
> >
> > Goal of this thread is to feel the overall trend and see if we can
> refine>
> > the proposals (for example: can we drop 3.8 one and only keep 3.7 and
> 3.6>
> > or - best - can we refine it to a single version after some exchanges).>
> > If we keep a few proposals after some days, what about a vote where the>
> > majority wins - we would just need to define how we count,>
> > bindings/committers/all (my preference being last one indeed)?>
> >
> > Romain Manni-Bucau>
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog>
> > <https://rmannibucau.metawerx.net/> | Old Blog>
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |>
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book>
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >>
>
> >
>


--
Arnaud Héritier
Twitter/Skype : aheritier