maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Jensen <>
Subject Re: Preleminary Maven 3.4.0-SNAPSHOT Testing
Date Sat, 02 Jul 2016 13:53:33 GMT
Feature toggles +1 FTW

Agreed, switching the default behavior over time is a good path of change.
Perhaps helping with the awareness of the feature, when the feature is off,
display an info message stating this feature exists and suggest enabling it
with the toggle, possibly noting future plans of it becoming the default

On Sat, Jul 2, 2016 at 7:06 AM, Jason van Zyl <> wrote:

> 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:
> >
> Thanks,
> Jason
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Takari and Apache Maven
> ---------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message