maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <>
Subject Re: Preleminary Maven 3.4.0-SNAPSHOT Testing
Date Sat, 02 Jul 2016 12:06:23 GMT
The question is not whether to fix them, but how they are fixed in the context of the people
using the software.

I think you strive for the pure, elegant and correct way of how you think something should
work. In most cases I’ve seen your reasoning is sound and in most cases is what should be
done but how those corrections are delivered is as important as the fix itself. For whatever
mistakes we have made we have hundreds of thousands, if not millions, of users who still need
to do their daily work. Yes, they come to expect Maven to work as if it was a product they
purchased and while that may seem unreasonable that is the situation we are in.

I think for all the corrections you are making, it’s fine if they land in 4.0 where it’s
documented that for a given correction where their POM looks like X it must look like Y to
be correct. It’s a conscious choice on the part of the user to get the benefits of newer
versions and to receive these benefits there are some behavioral changes that accompany those
benefits. Maybe we can write something that looks for these patterns and helps users correct
the errors. But this really can’t happen across a minor version as it’s just not expected.
For one change we make where we don’t make this clear we potentially accrue thousands of
man hours of pain from users and to me the math is clear this is not a good option. We have
lots of baggage but we have to live with it and I believe we have to live with it because
that’s what makes it work for all our users.

We have historically gone to great lengths with the ITs to ensure behavior has remained stable
so that for the vast majority of our users things don’t break. Maybe that has kept us from
fixing some fundamentally incorrect behavior but it has preserved the utility delivered to
our users. So we need to figure out a way to deliver the new behavior while preserving the
old for a time being. Maybe a branch, but I think the best way to do it is to have both behaviors
exist in the same codebase and turn on what we considered corrected behavior with feature
toggles. Users can opt in early if they want to see the potential benefit but it won’t affect
users adversely or unintentionally. Eventually over time the new behavior becomes the default
and the old behavior can be toggled for the stragglers. Sure we can just throw away the old
behavior but I honest think the downstream impact will be enormous, and in a negative way.

> On Jul 2, 2016, at 7:07 AM, Christian Schulte <> wrote:
> Am 07/02/16 um 12:36 schrieb Oliver B. Fischer:
>> My suggestions is based on the view of a Maven user who would like to do 
>> it's daily job ;-)
>> In our team we have > 20 Maven projects and as a Maven 'User' you need 
>> the chance to fix such issues before the break your build. Everyone 
>> would blame Maven for this. We should have the chance to fix these 
>> problems before they become serious.
>> WDYT?
> It's a matter of how you plan Maven upgrades. I understand you just want
> to download a newer Maven version without having to do anything else. As
> already said, the commits in question have been reverted for 3.4. Think
> about upgrading Maven is like upgrading your operating system. You are a
> developer yourself. How do you fix bugs without fixing them?
> Regards,
> -- 
> Christian
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:



Jason van Zyl
Founder, Takari and Apache Maven

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message