Rules developers should adhere to
- The decision when to move a version number is taken by the project
administrator (currently bela). Just drop me an email if you want to
increment a minor version number and I'll ok it. This prevents
multiple developers from incrementing the same version number. With
minor relases this is usually not a big deal and I'll do it
- Do not modify core functionality (e.g. Protocol, GMS, FC, UNICAST, NAKACK, STABLE, CoordGmsImpl etc)
before consulting with one of the project administrators.
- New tarballs are done by the project administrator. I may delegate
this in the future (to a number of people), but I decide when to add
a new tarball to the download section.
- Don't use any functionality found in JDKs higher than the one
JGroups is currently using
- Don't use any functionality not found in the reference JDK
(e.g. from Microsoft's proprietary JDK implementation)
- There are NO restrictions with respect to programming style. Just be
coherent. SUN advocates use of fooBar() method style.
- If you modify a file 'owned' by someone else, try to adhere to
his/her style. Don't try to impose your style on that
person. Ownership is basically who created the file. Once you obtain
the ownership you can change the file if you want to.
- Try to write test drivers for your module(s) and add them to
JGroups/tests. We use TestNG (www.testng.org) for regression
testing. It is pretty simple to add a new test to the directory,
e.g. by just copying an existing test driver and modifying it.
- Add the <dollarsign>Id<dollarsign> identifier to the top of all your
files (<dollarsign> is a $, it cannot be written out otherwise it
would get expanded by the CVS)
- Use spaces instead of tabs, or make your IDE expand tabs to
spaces. In Emacs this can be done via the following code:
(setq-default indent-tabs-mode nil)
Bela Ban (email@example.com)
San Jose, March 13 2001
Dec 11 2002
April 5 2004