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 <[email protected]> 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, <[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] > > > > >
