All, 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 releases. I favour the latter, but am interested in others opinions. Pete _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

> Q : How will this work with Maven? Won't it be annoying for developers to > have to explicitly specify which module to depend on (and update this every > time a Seam bundle comes out)? > > We'll provide a so called "stack POM" [1], which users can import into > their project. They then just bump the Seam version number: > > <dependency> > <groupId>org.jboss.seam</groupId> > <artifactId>seam-bom</artifactId> > <version>3.0.2.CR1</version> > <type>pom</type> > <scope>import</scope> > </dependency> > > +1 This is where we get a lot of milage out of Maven (and dependency management in general). -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://www.google.com/profiles/dan.j.allen _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

I originally preferred the former idea, however after thinking about it for a while I've changed my mind. I think the release versions and project roadmap is just going to be too hard to coordinate for a bunch of independent modules with their own release cycles. With that in mind, if no-one has any objections I'll start arranging the creation of new JIRA projects for our modules, starting with the modules that are first out the door (remoting and xml). What does everyone think of a naming scheme of SEAM-REMOTING, SEAM-XML, etc? (The JB prefix I removed on purpose).

Could you also add SEAMINTL (international)?

On Thu, Mar 11, 2010 at 10:58 AM, Ken Finnigan < ken.finnigan(a)sorstech.com > wrote: Could you also add SEAMINTL (international)? SEAMI18N?

-Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://www.google.com/profiles/dan.j.allen _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

SEAMINTL it is..... Any other ideas, preferences? No numbers?... ridiculous. On Mon, Mar 15, 2010 at 11:41 PM, Rodney Russ <rruss(a)redhat.com&gt; wrote: ----- "Dan Allen" <dan.j.allen(a)gmail.com&gt; wrote: > On Thu, Mar 11, 2010 at 10:58 AM, Ken Finnigan < > ken.finnigan(a)sorstech.com > wrote: > > > > > Could you also add SEAMINTL (international)? > > > SEAMI18N? er ... apparently Jira does not like numbers in the Key. "You must specify a unique project key, at least 2 characters long, containing only uppercase letters." > > > -Dan > -- > Dan Allen > Senior Software Engineer, Red Hat | Author of Seam in Action > Registered Linux User #231597 > > http://mojavelinux.com > http://mojavelinux.com/seaminaction > http://www.google.com/profiles/dan.j.allen > > _______________________________________________ > seam-dev mailing list > seam-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev -- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com "Keep it Simple" _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

> Q: Will it be "simultaneous release" once a year like eclipse does? > > No, firstly a simultaneous release implies that each module does it's major feature updates at the same time, I don't see we need to stick to that. Instead we will bundle a set of compatible modules. Secondly, we aim to release more than once a year :-) What is the difference between "simultaneous release" and "bundle a set of compatible modules" ?

>> Q: Will it be "simultaneous release" once a year like eclipse does? >> >> No, firstly a simultaneous release implies that each module does it's major feature updates at the same time, I don't see we need to stick to that. Instead we will bundle a set of compatible modules. Secondly, we aim to release more than once a year :-) >> > What is the difference between "simultaneous release" and "bundle a set of compatible modules" ? > > I think what Pete is implying is that the modules don't have to be releasing at that time (or should not hold out the released until that date). Instead, we take what is stable at the time (pushing a release if absolutely necessary to integrate well) and then cut the bundle. But, to be honest, we're still in the process of establishing a strategy ;) > > Sure, and this is actually also what eclipse "simultaneous release" means - some projects release several times, some only at that time; but all are keeping an eye on that 1 a year big release and additional 2 bugfix releases to make sure their stuff gets done for it. in other words - without a planned "big" release nothing would actually work together ;)

/max _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

On Thu, Mar 18, 2010 at 5:31 AM, Andersen Max <max.andersen(a)redhat.com&gt; wrote: > > Q: Will it be "simultaneous release" once a year like eclipse does? > > > > No, firstly a simultaneous release implies that each module does it's major feature updates at the same time, I don't see we need to stick to that. Instead we will bundle a set of compatible modules. Secondly, we aim to release more than once a year :-) > > What is the difference between "simultaneous release" and "bundle a set of compatible modules" ? > > I think what Pete is implying is that the modules don't have to be releasing at that time (or should not hold out the released until that date). Instead, we take what is stable at the time (pushing a release if absolutely necessary to integrate well) and then cut the bundle. But, to be honest, we're still in the process of establishing a strategy ;) > Sure, and this is actually also what eclipse "simultaneous release" means - some projects release several times, some only at that time; but all are keeping an eye on that 1 a year big release and additional 2 bugfix releases to make sure their stuff gets done for it. in other words - without a planned "big" release nothing would actually work together ;) We'd find your team's experience and advice from working with the Eclipse simultaneous release process a valuable resource, when the time comes for us. No doubt, we are the newbies in this realm ;)

All, 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 releases. I favour the latter, but am interested in others opinions.

Would I like to go to project per module ? Yes, but not until jira gets cross-project tracking and that we don't have to coexist within a UI that lists 50+ projects that all start with the same prefix

People, 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. Pete On 10 Mar 2010, at 11:57, Pete Muir wrote: > All, > > 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 releases. > > I favour the latter, but am interested in others opinions. > > Pete > _______________________________________________ > seam-dev mailing list > seam-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

On 14 Apr 2010, at 12:05, Shane Bryzak wrote: > We now have the following SEAM project in JIRA: > > https://jira.jboss.org/jira/browse/SEAM > > The plan is to eventually remove the JBSEAM project, Well, we won't remove it, so much as close it to new traffic. > 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. > > Shane > > On 14/04/10 20:02, Pete Muir wrote: >> People, >> >> 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. >> >> Pete >> >> On 10 Mar 2010, at 11:57, Pete Muir wrote: >> >> >>> All, >>> >>> 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 releases. >>> >>> I favour the latter, but am interested in others opinions. >>> >>> Pete >>> _______________________________________________ >>> seam-dev mailing list >>> seam-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/seam-dev >>> >> >> _______________________________________________ >> seam-dev mailing list >> seam-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/seam-dev >> > _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

On Wed, Apr 14, 2010 at 8:15 AM, Jordan Ganoff <jganoff(a)gmail.com&gt; wrote: Please create a JIRA project for the Seam 3 JMS Module: SEAMJMS Can I document the procedure for requesting a JIRA project in the module lead handbook? What's the proper procedure? -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://www.google.com/profiles/dan.j.allen _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

People,

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 ;-)