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]
