Thanks for clearing that up. One step closer to choosing the version number.
On Sun, 28 Mar 2021, 12:05 Tibor Digana, <[email protected]> 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 <[email protected]> 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, <[email protected]> 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: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > >
