On Fri, 4 Oct 2019 at 12:39, Aleksandar Kurtakov <akurt...@redhat.com> wrote:
> On Fri, Oct 4, 2019 at 2:22 PM Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > On Fri, 4 Oct 2019 at 12:03, Michael Osipov <micha...@apache.org> wrote: > > > I also won't participate in any further in-depth discussion > > > for 3.7.0 for the reasons I have mentioned previously. I just don't see > > > it fruitful. > > > The technical debt we have is huge and we are not able to handle it. > > > > > > > There is a chicken and egg situation though. A lot of the technical debt > we > > have is fall-out from being unable to evolve the pom. We cannot evolve > the > > pom without being able to split the build vs consumer pom, thus we keep > > leaking the technical debt. > > > > And potential contributors will keep getting pushed away until we > provide a > > pom evolution path. > > > > We need more contributors, but to get them we need a way to help them > > scratch their itches. > > > > 3.4.0 was the result of a new contributor trying to make progress... but > > because we didn't have a clear path to solve evolution we ended up > burning > > that individual as a contributor. > > > > We need an evolution path. > > > > Just Maven user here but involved in a number of other FOSS projects. We > are seeing significant improvement in number of new contributors and their > longevity since relaxing a bit the rules to not be all about supporting > ancient versions of everything. And a project is its contributors - not > managing to attract new guys and old guys getting tired is probably hardest > one to solve. > There is also the marketing effect of requiring to support old versions. When you say "oh must work on _insert_really_old_thing_" you are really saying "we are not modern". The paradox is that people want to work on modern stuff... but they really want rock solid stable from the stuff they rely on. So as a project, Maven needs to try and maintain our reputation for rock solid stable... but we cannot do that if there is nobody to work on the project... and getting people to work on the project requires an element of "we are modern" Now for a build tool, I think Java 11 is "too modern" right now... but Java 8 is around a long time now... I personally think it has been time to move for a while now... but we have been lacking the reason (i.e. "lets switch everything to lambdas is not a good reason") We now have a reason in the XML APIs that Robert's changes require... thus we move to Java 8 IMHO
