Simon Lessard schrieb:
Hi Paul, Simon and others,
I guess those are valid concerns, but I see one evolutivity problem,
even with a private copy. Let say you have:
1. Shared class A with method foo() in shared x.y.1
2. Core 1.2.1 uses that method as well as Tomahawk 1.2.1
3. For Core 1.2.2, a change is required to foo's contract, releasing
shared x.y.2. For now everything is good since Tomahawk has a private
copy of x.y.1
4. Tomahawk 1.2.2 also need a change to foo's contract, but not the
same as Core 1.2.2 and furthermore excluding the changes needed so
applying the change to shared from x.y.1 base, causing a new release
of shared x.y.3. Still everything is fine.
From that point onward though, foo method will have to get reverted
back and forth for both projects in order to include other fixes and
improvements, no?
Yep. So in that case either a method foo2() needs to be created, or a
class A2. Hopefully that doesn't happen too often.
As for the current structure, I'm not adamantly against it, so given
we keep it, do you think I shared rebranch it for 2.0 or try to use 3.0.x?
I would suggest using 3.0.x until you find that something just won't
fit, and branch it then.
I guess the danger with that is that you could add a bunch of code that
only 2.0.x needs and then find you need to branch anyway, leaving a
JSF1.2-specific "shared" version containing code that nothing is using.
But the disadvantage of forking is obviously that patches need to be
applied to multiple branches. Where's that crystal ball :-)
Regards,
Simon
