We now have the following SEAM project in JIRA:
The plan is to eventually remove the JBSEAM project,
after all of its issues have been addressed in some way or another.
As Pete said, all Seam 2 issues should stay put in the JBSEAM project, and Seam 3 and
higher issues should now go in SEAM.
On 14/04/10 20:02, Pete Muir wrote:
> We still need an issue tracker for tracking common Seam tasks:
> * Build infrastructure
> * Common documentation
> * Shared examples
> * Simultaneous release tasks
> * A dumping ground for "new-users" to put issues which they don't know
where they belong (it's then up to us to triage them to the correct place).
> As we've diverged so much from Seam 2, I propose we create a new project in JIRA,
SEAM, and keep JBSEAM for Seam 2 issues. This should reduce cross-over confusion between
the two codebases' issues. It also has the nice sideeffect of allowing us to get rid
of the unneeded JB prefix ;-)
> If anyone disagrees, speak up. Otherwise I'll ask Rodney to do this later today.
> On 10 Mar 2010, at 11:57, Pete Muir wrote:
>> As we split Seam into modules (and as some like remoting and XML approach a beta
release), we need to consider how JIRA should look for Seam 3.
>> We plan to release modules independently, with a "feature-boxed"
lifecycle, releasing modules either as features are added, or critical issues arrive. We
also plan a "bundle release" at regular intervals, which takes all the modules,
and provides a single stack that are tested to work well together.
>> Keeping JIRA simple and monolithic has the advantage of being easy to understand
and point people at. We can use components to track a module. We would have to prefix the
version with the module name, and tracking issues to releases becomes pretty difficult.
>> Using a JIRA project for each module allows much cleaner tracking of issues to
>> I favour the latter, but am interested in others opinions.
>> seam-dev mailing list
> seam-dev mailing list