[wildfly-dev] Patching WSDL4J (or perhaps forking?)

[Max Rydahl Andersen]

Reason to change G - make it so you can use both libraries in your dependency tree.
Reason to keep G - make it so you can't use both libraries in your dependency tree.

(there are more but that one is the key reason enterprise builds just uses V changes,
so you don't mix original project with the supported one by accident.)

/max

On Fri, Sep 06, 2013 at 09:08:21AM -0500, Brian Stansberry wrote:
>On 9/6/13 8:32 AM, Alessio Soldano wrote:
>> Hi Brian,
>>
>> On 05/09/13 18:34, Brian Stansberry wrote:
>>> You can also fork/join. :)
>>>
>>> If a critical bug is blocking major downstream projects at some point
>>> there's no choice other than forking. But if they ever fix the problem
>>> you can always abandon the fork.
>> Sure.
>>
>> Btw, I've tried creating a new bug at
>> https://sourceforge.net/p/wsdl4j/bugs/ after having logged with my
>> sourceforge account, but looks like I don't have enough permissions...
>>
>>> I'm curious: when we've forked, what's the proper approach to release
>>> naming? A different "G" in the maven GAV, or just a different "V"?
>> I would go with a different V (suffixed with jbossorg).
>>
>
>Sounds fine.
>
>I realize now I was muddled in my thinking when I asked this question.
>Your fork is different from most -redhat productization rebuilds because
>you are changing source, not just rebuilding. But, whether a fork
>changes the G, the A or the V the original version string (1.1.1.GA or
>whatever) is going to remain as part of the V, even though the code has
>changed. So there's no real advantage in changing the G instead of
>adding a suffix to the V.
>
>
>-- 
>Brian Stansberry
>Principal Software Engineer
>JBoss by Red Hat
>_______________________________________________
>wildfly-dev mailing list
>wildfly-dev at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/wildfly-dev