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 <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io --------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
