On Tue, Jul 14, 2015 at 11:48 AM, Jason van Zyl <[email protected]> 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'? 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. I considered, even, sending email proposing to remove the long-deprecated goals from this plugin. 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. > >> On Jul 14, 2015, at 11:36 AM, Benson Margulies <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>> 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: [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] >>> >> >> --------------------------------------------------------------------- >> 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 > --------------------------------------------------------- > > A language that doesn’t affect the way you think about programming is not > worth knowing. > > -- Alan Perlis > > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
