> On Jul 14, 2015, at 11:59 AM, Benson Margulies <bimargul...@gmail.com> wrote: > > On Tue, Jul 14, 2015 at 11:48 AM, Jason van Zyl <ja...@takari.io> wrote: >> Ultimately your call. If users can upgrade and existing configuration will >> work there’s no issue. If it breaks the user simply upgrading for something >> you need need for expediency not so much. If it’s the first case there’s no >> issue, if it’s the second then I would take the 15 minutes to make it >> backward compatible and therefore a non-issue then it’s win-win. I have no >> issue with any committer punching in fixes, even for self-interested >> reasons, but personally I try my best to make it transparent over upgrades. > > Jason, thank you. I completely agree about transparency in general. It > seems to me that this hinges on the definition of 'works'. Does adding > an unwanted file to the output constitute 'not working’?
User upgrades and it doesn’t work I consider not working. Maven plugins are different than libraries and unless you are adding major feature changes it doesn’t warrant a signal to a user that all is going to break. Especially in this where it can be avoided. People who run the build are often not the people who setup the build and that person is often not around so making breaking changes to configurations on teams is super disruptive. > I could > imagine arguments in both directions. The other consideration here, in > my head, is that there's a cost to an ever-growing list of obscure > options in the assembly descriptor, and that a major version boundary, > teed up for other good reasons, is an opportunity to clean house. Yes, but that is unlikely to happen. I highly doubt your change is going to trigger a wholesale cleanup of one of the most complicated plugins we have. And even if it was done it should still be done iteratively for something like the assembly plugin. People who look forward to a super new assembly plugin where they have to fiddle with their configuration to make it work are in the vast minority. It’s the configuration of the plugin which is the most important and the way Maven plugin configuration works it’s pretty much possible 100% of the time to preserve a pre-existing model. You can make wholesale changes, preserve the model, keep existing users happy and allow new users to consciously make the choice to change their configuration to take advantage of new features. That’s really the only sensible path we have for most of our plugins. The onus is on us to make things work for as long as humanly possible. That’s the nature of build infrastructure. > I > considered, even, sending email proposing to remove the > long-deprecated goals from this plugin. > Again, I think the vast majority of people don’t really look at these. If the build works they carry on, that’s just the nature of the behaviour of most Maven users. In developing applications I’m somewhat different but for build infrastructure I tend to ignore my indignation and “unclean” code and the inelegance of some of our systems. We live with our baggage and if you want to improve it, it certainly can be done but it just has to be done with care. Your example here for a major change just seems unwarranted. > For now, I've decided to hold off a day or two and see what other > people think; I have a local workaround. And for the record, this > isn't 'my client', this is me doing my day job using Maven where I ran > into this. > If it’s easy to make compatible why would you not do it? > > >> >>> On Jul 14, 2015, at 11:36 AM, Benson Margulies <bimargul...@gmail.com> >>> wrote: >>> >>> Jason, I don't think that this constitutes a punch in the face of >>> anyone for any purpose. >>> >>> Did you actually read the JIRA? I've removed a file exclusion from >>> file sets. So, if someone was depending on the undocumented fact that >>> the assembly plugin would refuse to copy a file named (e.g.) >>> lexicon.filtered, they will now find this file in their output, if and >>> only if they upgrade to 3.0.0; and then, if they don't like it, they >>> need to add in an <exclude>. That's what major release numbers are >>> for, in my view. >>> >>> I don't see that as aggressive. I see it as correcting an obscure bug. >>> I describe it as 'incompatible' because it does change behavior. >>> However, I also claim that the behavior was a bug, not a feature. It's >>> not documented, it's contrary to the pattern that users can control >>> excludes and includes. >>> >>> No one is forced to use assembly 3.0.0. People can use 2.5.5. People >>> who care can make a branch and make 2.5.6. >>> >>> In other words, I accept your logic in general, but I don't agree that >>> it's applicable to these particular circumstances. If I felt that it >>> was even faintly useful to retain this behavior, I'd add a new boolean >>> to the model to retain the behavior by default. But it seems stupid to >>> me to add the conceptual overhead for that purpose. >>> >>> However, if the community wants a boolean, I'll knock in a boolean, >>> and then release. It would be called: >>> >>> <useDefaultFilteredFormattedExcludes> >>> >>> and it would be true by default. >>> >>> Heck, if even one member of the community really thinks that backwards >>> preservation of this bug across a major release boundary is >>> worthwhile, I'll do it. It will take 15 minutes. >>> >>> >>> >>> >>> >>> On Tue, Jul 14, 2015 at 11:28 AM, Jason van Zyl <ja...@takari.io> wrote: >>>> This is why I keep stuff that I want to move on a >>>> self-interested/aggressive path not at Apache. What’s here needs to >>>> consider the best interest of all users. >>>> >>>> If you’re basically going to make the next version incompatible for anyone >>>> who upgrades because you need something I don’t think that’s acceptable. >>>> >>>> I think taking some liberties is fine if you’ve contributed a ton, but if >>>> every user of the assembly plugin is going to get punched in the face when >>>> they upgrade to the only available next version I think that’s pretty >>>> crappy. You should fork it and make your client use your fork, it should >>>> be your problem not every users problem because you need an expedient fix. >>>> I hold on to spot fixes for customers for months until I can find a way to >>>> make it work generally or I just maintain the fork. >>>> >>>>> On Jul 14, 2015, at 11:15 AM, Benson Margulies <bimargul...@gmail.com> >>>>> wrote: >>>>> >>>>> I have selfish/professional reasons to desire a release with a fix to >>>>> MASSEMBLY-777, and the fix, involving an intentional incompatibility, >>>>> needs to be 3.0.0, and, anyhow, the pom is all set up for 3.0.0 to be >>>>> next. So I plan to start the process tomorrow morning EDT unless >>>>> someone objects. >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>> For additional commands, e-mail: dev-h...@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: dev-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> Thanks, >> >> Jason >> >> ---------------------------------------------------------- >> Jason van Zyl >> Founder, Takari and Apache Maven >> http://twitter.com/jvanzyl >> http://twitter.com/takari_io >> --------------------------------------------------------- >> >> A language that doesn’t affect the way you think about programming is not >> worth knowing. >> >> -- Alan Perlis >> >> >> >> >> >> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io --------------------------------------------------------- We all have problems. How we deal with them is a measure of our worth. -- Unknown --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
