Title: Development Process license: https://www.apache.org/licenses/LICENSE-2.0
River is built on the Apache Hudson server. The projects can be found here. More on this process: Continuous Integration
A JIRA issue is required for any substantive change. In order to keep the list of JIRA issues under control, it is expected that any controversial issue or user request for a feature or design change be discussed on the dev list prior to entering it into JIRA.
JIRA issues are not needed for small (e.g., typos) changes.
Issue discussions The preferred place of discussion on issues is the river-dev mail list. A link to the beginning of the mail thread on the issue should be placed in the JIRA issue so that users looking through JIRA can easily view the thread of discussion on an issue. Please keep the Subject line the same so that the email thread hangs together. It's also recommended that a summary/conclusion on the thread be recorded in the JIRA issue itself.
There are three options associated with the “Security Level” field in the JIRA instance:
When a potential security -related issue is identified in the River sourcebase, initial discussion on it should occur on the private PPMC list. If the person(s) who identified the issue are not on the PPMC, they should be included in the discussion.
If the issue is acknowledged as a valid security issue, a JIRA issue needs to be created with the “Security Level” field marked to “Security risk, visible to committers”.
As soon as appropriate (for example, when the impact is understood and/or there is a resolution/fix developed), the “Security Level” should be changed to “Security risk, visible to anyone” and an explanation/discussion should occur in the broader River community on the river-dev list.
for public API changes: RTC These changes have potentially broad effects on developers and users, and therefore will require a code review and vote. Since some of these changes will affect the API docs (‘specs’), everyone within the Jini/River community is encouraged to review and vote. The Committer votes are binding, but the sentiment of the entire community will be strongly considered.
for all other changes: CTR Although CTR is what is specified, developers should feel comfortable requesting the list for peer review before committing.
Developing test cases and running test suites are desired but not required prior to an integration. If unit tests are created for a change, the developer is encouraged to add them to the JIRA issue for sharing.
Here is a list of individually executable test categories.
<div class="modal-body">
<div class="list-group">
<a href="#" class="list-group-item">activation</a>
<a href="#" class="list-group-item">activation_spec</a>
<a href="#" class="list-group-item">allgroups</a>
basicinvocationdispatcher basicinvocationdispatcher_spec basicinvocationhandler basicinvocationhandler_spec basicobjectendpoint basicobjectendpoint_spec config config_spec constraint constraint_spec coreconstraint coreconstraint_spec discardproblem discoverymanager discoverymanager_impl discoverymanager_spec discoveryproviders discoveryproviders_impl discoveryservice discoveryservice_impl discoveryservice_spec discoveryserviceevent discoveryservicelease end2end end2end_impl eventmailbox eventmailbox_impl eventmailbox_spec export export_spec fiddleradmin fiddlerfiddleradmin fiddlerjoinadmin id id_spec iiop iiop_spec impllocatordiscovery impllookupdiscovery implservicediscovery implservicediscoveryevent io io_spec javaspace javaspace05_conformance javaspace_conformance javaspace_impl javaspace_impl_admin javaspace_impl_api javaspace_impl_javaspace05 javaspace_impl_leasing javaspace_impl_matching javaspace_impl_notify javaspace_impl_transaction javaspace_spec jeri jeri_spec joinmanager joinmanager_impl joinmanager_spec jrmp jrmp_spec loader loader_spec locatordiscovery locatordiscovery_impl locatordiscovery_spec lookupdiscovery lookupdiscovery_impl lookupdiscovery_spec lookupservice lookupservice_impl lookupservice_spec policyprovider policyprovider_spec proxytrust proxytrust_spec reliability renewalmanager renewalmanager_spec renewalservice renewalservice_impl renewalservice_spec scalability security security_spec servicediscovery servicediscovery_impl servicediscovery_spec servicediscoverycache servicediscoverydiscovery servicediscoveryevent servicediscoverylookup snapshot spec speclocatordiscovery speclookupdiscovery specservicediscovery specservicediscoverycache specservicediscoverydiscovery specservicediscoveryevent specservicediscoverylookup start start_impl stress test_set00 test_set01 test_set02 test_set03 test_set04 thread thread_impl txnmanager txnmanager_impl txnmanager_spec url url_spec Close
Each Apache River deliverable has a version number of:
m.n.r
m = major versionn = minor versionr = maintenance versionThe major version number will in general only be increased in case of major changes that might introduce compatibility problems or represent some fundamental improvements. The minor versions reflect the various feature releases, the last part of the version number reflects the maintenance release.
Ongoing development for the next release takes place in the /trunk. Once feature complete for a (non maintenance) release the trunk is branched into /branches/<m.n> which in general also reflects the moment a release candidate is presented to the public in a fairly short period of time. Ongoing development continues in the /trunk, issues found against the release candidate will be fixed in /branches/<m.n> and likely merged into the /trunk.
Once a release candidate is ready for a first customer release /branches/<m.n> is branched into /tags/<m.n>.0. When support is required for a particular release m.n, the development for a fix-release is conducted in /branches/<m.n>. When a bug-fix release is ready it is branched into /tags/<m.n.r> where r is a positive number and increased for each maintenance release.
Although ongoing development should take place in /trunk, there is a /skunk branch that can be utilized for ‘experimental’ work that must not disturb the /trunk, that needs to be visible to others and/or might require participation of others. In general the lifetime of such branch should be short to give it a chance of successful integration into the /trunk when the ‘experiment’ has been found valuable.
Summarized
| branch | description |
|---|---|
.../river/<product>/trunk | mainline development |
.../river/<product>/branches | maintenance branches |
.../river/<product>/tags | frozen release tags |
.../river/<product>/skunk | development and ‘skunk works’ branches |
Tabs are not used. Default indentation is 4 spaces.
Contributors are advised to read the Code Conventions for the Java and try to adhere as much as possible to these conventions.
If the reformatting involves a large part of the code, a clearly labeled ‘reformatting’ commit in between is recommended. Keeping your reformatting changes limited, reduces the change of merging conflicts by your fellow committers.
We do not actively search and reformat source files that are not formatted according to this convention.
Older sources are best viewed with tab stops at 8 space intervals.