I'll go along that path then. I think I will be able to avoid putting anything 2.0 specific methods in it.
Thanks, ~ Simon On Tue, Sep 30, 2008 at 10:30 AM, Simon Kitching <[EMAIL PROTECTED]>wrote: > 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 > >
