The base jNetPcap SVN directory and commands to checkout the source code are:
svn co https://jnetpcap.svn.sourceforge.net/svnroot/jnetpcap/jnetpcap/trunk svn co https://jnetpcap.svn.sourceforge.net/svnroot/jnetpcap/protocols/trunk svn co https://jnetpcap.svn.sourceforge.net/svnroot/jnetpcap/swing/trunk
The following layout for modules, trunks, tags, branches and releases are used.
jnetpcap/ <= jnetpcap module trunk/ <= latest development builds/ <= development snapshots jnetpcap-1.3/ <= trunk snapshots - 1.3 feature set trunk-1.3.b0001.milestone1 <= last dev build releases/ <= official releases jnetpcap-1.2-deprecated/ <= deprecated stuff, previous released release-1.2.rc1 release-1.2.rc2 release-1.2.rc2.1 release-1.2.rc4.1 release-1.2.rc4.2 release-1.2.rc5 jnetpcap-1.2/ <= version 1.2 release jnetpcap-1.2.preview1 <= pre-alpha, 1st release jnetpcap-1.2-alpha1 <= frozen feature set jnetpcap-1.2-beta1 <= bug fixes, almost stable jnetpcap-1.2-rc1 <= nearly stable, last check jnetpcap-1.2-stable <= final release jnetpcap-1.2.1-rc1 <= maintenance release candidate jnetpcap-1.2.1-stable <= stable maintenance release jnetpcap-1.3/ <= version 1.3 release trunk-1.3.preview1 trunk-1.3.alpha1 branch-1.3.alpha2 branch-1.3.beta1 tags/ <= important events trunk-0.X/ <= trunk tags pre the first 1.0 release trunk-1.X/ <= various trunk tags post 1.0 release trunk-1.2/ <= various trunk tags post 1.2 release branch-1.2/ <= various branch tags post 1.2 release branches/ jnetpcap-1.2 <= release incubation area until maturity "stable" protocols/ <= extra protocols module trunk/ <= latest development builds/ <= dev snapshot builds protocols-2.0/ <= 2.0 protocol feature set releases/ <= official releases tags/ <= special events branches/ <= incubation area for official releases swing/ <= swing components trunk/ <= latest development
modules directory
Each module has a single top level directory named either "jnetpcap/" or "protocols/". The trunk, tags, builds, releases and branches directories are all sub-directories of the top level module directory.
tags directory
Every so often, it is necessary or advantageous to be able to tag the status of a particular trunk that has been under development. These tags go into the "tags" svn directory. They do not correspond to any particular release, they are a snapshot of the trunk at a particular time and stage in development.
releases directory
Is another directory used for tagging trunk or branch code trees. It is used to tag a trunk of a module at a particular time with the intention of making a public release. First the tag is created and software packages built based on that tag. This provides a way to be able to recreate any previously released software package.
branches directory
Branches directory is used for parallel development of a module. Especially after software has been released and needs updates. The typical release sequence requires not only that a tag be made but also a branch of a particular release.
For example. jnetpcap module X.Y.alpha1 is released. First a tag is made under the "tags" directory. All new development on the released software is frozen, but the module's trunk directory continues to be modified and new features worked on. At some point, the alpha1 release needs to become a "jnetpcap.X.Y.beta1" release. This change-over happens on the "jetpcap.X.Y" branch. The branch is tagged as "jnetpcap.X.Y.beta2". Therefore the branch becomes a local development branch for the X.Y release, inorder to fix whatever needed to be fixed, not for active new development. The "tags" directory contains pure unaltered snapshots of each release and allows us to go back to any particular release, exactly.
builds directory
jnetpcap/builds/jnetpcap-1.3/trunk-b0001-f445
These are daily, weekly, or special event builds that are released. These builds are typically of the module's trunk, but may also be a special build of a branch directory of a parallel development that has been branched off.
trunk tells where the SVN tag came from. This was a trunk snapshot, as it will mostly be for dev snapshots. It could however come from branches too, which would be indicated by "branch-b0001-f445".
b0001 is the zero padded, 4 digit build number for this module. Its always incremented after each build.
f445 is a "feature" number that was added to this build, since the last build. If there were no more features added to this build we list the previous feature numbers. So if for example a defect was fixed, the same name is used as when the defect was discovered, but the build number is incremented.
We only use the last 3 digits of a feature or defect number if its longer. If there is a conflict with a previously used number we add any number of digits necessary from the original number until the number become unique. This shouldn't happen too often, but its certainly possible. This will shorten these names and will also be easier to remember 3 digit feature and bug numbers then the entire 6, 7 or 8 digit feature numbers assigned by the bug tracking system. This convention is here to help us and make our lives easier, rather than to complicate them unnecessarily.
Other optional names that can be included are "d123". Anything that starts with a "d" is a defect and a defect number. "t" timebased (with DATESTAMP appended), "f" is a feature. "j" is a journal. "p" is a patch that was applied etc... Daily/timebased builds do not shorted the number of digits used and use the full 8 digits since the daily tag usually appears by itself.
Of course other names can be used as well such as special names "milestone", or "checkpoint", etc.. Whenever possible though, regular snapshots should try and include the detailed feature number and bug fixes that are addressed by the release. This type of convention should encourage frequent releases as soon as bugs are fixed or new features are added in.