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