+1 to the reorganization. I too feel this is the only way to release the 'Core' separate from any components, and that separate releases are vital to all of the MyFaces projects.
> -----Original Message----- > From: Manfred Geiler [mailto:[EMAIL PROTECTED] > Sent: Friday, February 17, 2006 3:43 AM > To: MyFaces Development > Subject: New MyFaces JIRA structure > > Hi all, > Sean already posted some thoughts recently. I know we should bring out > our next release first, but meanwhile we could have some thoughts > about future JIRA structure and version management. > > Here is a short roundup of what we have: > > MyFaces (sub-)projects on the site: > API > Impl > Commons > Tomahawk > Sandbox > (Tobago) > > We will release the following assemblies with different release numbers: > Core (= API + Impl) > Commons > Tomahawk (with or without Sandbox?) > (Tobago) > > I propose the following Jira-Projects: > MYFACES > MYFACES-COMMONS > MYFACES-TOMAHAWK > MYFACES-TOBAGO > > All four would have the common Jira category "MyFaces". So they will > still be tied together. > > There were some discussions regarding Commons in Jira. IMHO this is > the only solution, that is logical and does not lead to additional > confusion. Commons will have it's own release cycles - there is no > other way to solve this without having unwanted peculiarities. Some > alternatives, that where discussed recently: > * A custom field "Affected Commons Version": What about the "Fix > Version"? Where do I document it. Another custom field "Commons Fix > Version"? No, no, please. > * Request a JIRA enhancement? Not possible within a realistic time frame IMHO. > > So, what is the real drawback? The only one I can think of (and was > noted in former discussions) is, that people will report Commons bugs > in MYFACES. Well, moving issues between Jira projects is no big deal > as already was said. And: The very same applies to Tomahawk issues. > Many many Tomahawk bugs will be reported in MYFACES, because there > will always be cases where it is not so clear which sub-projects is > causing the actual problem. > So, it's always the developer's job to finally put the issue into the > right category, project, component, or whatever. > > Thoughts? > > Manfred
