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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev