Jump to: navigation, search

Difference between revisions of "Which Codeline"

 
Line 1: Line 1:
== Which codeline to use to make a contribution ==
+
== Which codeline to check out of CVS to make a Contribution ==
 
=== Q: Which version of BIRT do I check out to make a contribution to the current development branch? ===
 
=== Q: Which version of BIRT do I check out to make a contribution to the current development branch? ===
  

Revision as of 13:53, 17 January 2007

Which codeline to check out of CVS to make a Contribution

Q: Which version of BIRT do I check out to make a contribution to the current development branch?

Select /cvsroot/birt > HEAD > source.

Q: Can I contribute a patch to a previously release (stream) of BIRT?

Yes, bugs can be backported to previous release streams. A release stream is created for each 2nd digit release. For example there is a 2.1.x release stream, and a 2.2.x release stream. However, sometimes it is only possible to back port a bug from the current release, say 2.2 to 2.1.2 but not 2.1.1 since the latest release vehicle for the 2.1.x stream is 2.1.2.

However, such a back port also depends on the risk and scope of changes on the code base. The committer for the related component will evaluate the risk of back porting a bug. When a committer decides to back port a bug, he/she will check into the target release CVS stream, and update the tag and map files to include the fix in the next build on that stream (the 2.1.2 stream for example).


Q: When contributing a patch, is it necessary to note in the bugzilla entry which version of BIRT the patch was created from? (Especially in the case above.)

Yes, please set the target milestone to that release, and if the fix is for multiple releases, please set the target release to the latest one, but also put in a comment that all release streams need this fix.

Q: Is it a requirement to run all JUnit tests against any patch submitted? Against some patches? How is this determined?

It is recommended to test as much as you can with you patch. But the committer(s) who reviews and checks in the patch will also run the unit tests before before check in. Frequently, they might also revise the patch before check in.