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]
