Dot Releases

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Dot Releases

portal on behalf of Scott Rosenbaum
All,

I have been thinking some more about the topic of 2.1.X releases over the next year.  I think that planning for 2.1.1 to be timed with the platform release of the same is a really good idea.

I think that we may want to consider additional planned 2.1.X releases.  I realize that we are fairly resource constrained over the next year, so we would want to limit the scope of these 2.1.X releases to a fairly narrow set of criteria.  The items I would propose for inclusion in 2.1.X release are:

1) Bugzilla Blocker bugs
2) Community Code Contributions
3) Bugzilla Critical bugs

I would prioritize items based on that type of schedule.  Obviously, if we come up to a release date and there are no changes that fit into one of those categories, then we would not do a product release.  The reason that I would like to see the releases as planned as opposed to adHoc, is that I think it would help other companies plan for any code contributions.  Up until now, the product has been moving so fast that it would be really difficult for any outside code contributions.  In the year following the release of 2.1, I think that we will have a much larger community of users, and I think that the number of worthy contributions will grow.  I think that things like the JDO data source from the JFire team could really add some functional improvement to BIRT at a relatively low resource cost.  I actually think that there are a lot of potential contributions:
 - Oracle RefCursor oda.jdbc extension.
 - XLS emitter
 - oda.hibernate extension
 - client side scripting control (browser scripting control)
 - RCP view components (report viewer, parameters, TOC) as opposed to running in a web environment

I am sure that analysis of the Bugzilla database could identify a number of other enhancements. 

I realize that there are a lot of other issues in the equation, like who is going to pay for those releases, but I think that we should way the potential gains in terms of constant product improvement, new features, and expanding the BIRT community in the equation.

Scott

_______________________________________________
birt-pmc mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/birt-pmc
Reply | Threaded
Open this post in threaded view
|

RE: Dot Releases

Wenfeng Li

An alternative is to release a BIRT extension package on BIRT 2.1.1.   The package will only contain the new plugin extensions that adds new data access ODA drivers and new emitters. A RCP/SWT based report viewer can also be released as a new package.   The benefit of this approach is that it helps users to avoid retesting/redeploy their entire BIRT integration.

 

Wenfeng

 

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Scott Rosenbaum
Sent: Wednesday, April 05, 2006 11:27 AM
To: BIRT PMC
Subject: [birt-pmc] Dot Releases

 

All,

I have been thinking some more about the topic of 2.1.X releases over the next year.  I think that planning for 2.1.1 to be timed with the platform release of the same is a really good idea.

I think that we may want to consider additional planned 2.1.X releases.  I realize that we are fairly resource constrained over the next year, so we would want to limit the scope of these 2.1.X releases to a fairly narrow set of criteria.  The items I would propose for inclusion in 2.1.X release are:

1) Bugzilla Blocker bugs
2) Community Code Contributions
3) Bugzilla Critical bugs

I would prioritize items based on that type of schedule.  Obviously, if we come up to a release date and there are no changes that fit into one of those categories, then we would not do a product release.  The reason that I would like to see the releases as planned as opposed to adHoc, is that I think it would help other companies plan for any code contributions.  Up until now, the product has been moving so fast that it would be really difficult for any outside code contributions.  In the year following the release of 2.1, I think that we will have a much larger community of users, and I think that the number of worthy contributions will grow.  I think that things like the JDO data source from the JFire team could really add some functional improvement to BIRT at a relatively low resource cost.  I actually think that there are a lot of potential contributions:
 - Oracle RefCursor oda.jdbc extension.
 - XLS emitter
 - oda.hibernate extension
 - client side scripting control (browser scripting control)
 - RCP view components (report viewer, parameters, TOC) as opposed to running in a web environment

I am sure that analysis of the Bugzilla database could identify a number of other enhancements. 

I realize that there are a lot of other issues in the equation, like who is going to pay for those releases, but I think that we should way the potential gains in terms of constant product improvement, new features, and expanding the BIRT community in the equation.

Scott


_______________________________________________
birt-pmc mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/birt-pmc