Mailing-List: contact users-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Users List" <users@maven.apache.org>
MIME-Version: 1.0
In-Reply-To: <4C805A84-4684-4D9C-9273-0B45BE732842@takari.io>
References: <5b57fe47-9869-6879-a828-c489ac62746a@gmx.de> <56c2a41f-6e55-13de-95fb-a39f61ff2339@swe-blog.net>
 <575DCF68.9080904@schulte.it> <97a368d2-2a40-082f-0480-71ac750447e0@swe-blog.net>
 <CABLGb9xQMm8vxA3U9w6MP-eQoTPeJ7P6RRTOPFDQywL=i=Z_mg@mail.gmail.com>
 <f794858a-3aca-bb6b-bcdd-1f1335bb14e0@swe-blog.net> <57685EB7.50804@apache.org>
 <577e4f6a-4a08-b213-18b1-bf8cfae55583@swe-blog.net> <5777A077.7030107@schulte.it>
 <4C805A84-4684-4D9C-9273-0B45BE732842@takari.io>
From: Jeff Jensen <jeffjensen@upstairstechnology.com>
Date: Sat, 2 Jul 2016 08:53:33 -0500
Message-ID: <CAKumxBwfJMZtwmepeg0np94tErNuB8Gw2PJCmghvwCn7Y04Rmg@mail.gmail.com>
Subject: Re: Preleminary Maven 3.4.0-SNAPSHOT Testing
To: Maven Users List <users@maven.apache.org>
Content-Type: multipart/alternative; boundary=001a113ad27890612a0536a76f6e
archived-at: Sat, 02 Jul 2016 13:54:06 -0000

--001a113ad27890612a0536a76f6e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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
behavior.


On Sat, Jul 2, 2016 at 7:06 AM, Jason van Zyl <jason@takari.io> 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=E2=80=99ve 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 hav=
e
> 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=E2=80=99s fine if they=
 land in
> 4.0 where it=E2=80=99s documented that for a given correction where their=
 POM looks
> like X it must look like Y to be correct. It=E2=80=99s a conscious choice=
 on the
> part of the user to get the benefits of newer versions and to receive the=
se
> benefits there are some behavioral changes that accompany those benefits.
> Maybe we can write something that looks for these patterns and helps user=
s
> correct the errors. But this really can=E2=80=99t happen across a minor v=
ersion as
> it=E2=80=99s just not expected. For one change we make where we don=E2=80=
=99t 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 baggag=
e
> but we have to live with it and I believe we have to live with it because
> that=E2=80=99s what makes it work for all our users.
>
> We have historically gone to great lengths with the ITs to ensure behavio=
r
> has remained stable so that for the vast majority of our users things don=
=E2=80=99t
> 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 i=
s
> to have both behaviors exist in the same codebase and turn on what we
> considered corrected behavior with feature toggles. Users can opt in earl=
y
> if they want to see the potential benefit but it won=E2=80=99t affect use=
rs
> adversely or unintentionally. Eventually over time the new behavior becom=
es
> 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 <cs@schulte.it> 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 wan=
t
> > to download a newer Maven version without having to do anything else. A=
s
> > 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: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> ---------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

--001a113ad27890612a0536a76f6e--