See the Git pages for more information, tutorials, etc.
ImageJ uses Maven for its project infrastructure.
Maven artifacts are published to the ImageJ Maven repository.
Releases are versioned with Semantic Versioning.
SciJava software projects manage tasks and priorities using GitHub Issues:
Previously, some projects used Trac for issue tracking and roadmapping, but all Trac issues are now being migrated to GitHub. See these links:
- ImageJ Trac roadmap - early ImageJ2 milestones
- ImageJ Features report - a high-level list of features slated for each release
- ImageJ Trac timeline - a fine-grained list of changes to ImageJ
What are issues for?
Issues and milestones are public-facing entities, yet their content can be highly technical to serve as a roadmap and implementation guide for developers. As we see it, the various audiences for issues and milestones, and their needs, are as follows:
|to know what's already been reported||Browse and search all open SciJava software stack issues.|
|to keep track of issues of interest||Subscribe to desired issues using notifications.|
|to know which issues were fixed in a release|| Browse issues at a particular milestone|
(e.g., 1.0.0 issues, 1.0.0 bugs, 1.0.0 enhancements).
|to track their current tasks|| Browse issues assigned to a particular developer|
(e.g., ctrueden, hinerm).
|to find new tasks to work on||Browse the "help wanted" label or unassigned issues.|
|a place to discuss implementation details, etc.||Use pull requests.|
|to easily see what needs attention||Browse issues without a milestone.|
|to ignore inactive issues without closing them||Use the "unscheduled" milestone.|
|to plan development timelines||Use future milestones (e.g., imagej, scifio).|
|to report completed features||Use completed milestones (e.g., imagej, scifio).|
To meet these needs, we use the following conventions with GitHub issues:
- For short-term active development, use names m1, m2, etc.
- As these milestones are closed, they are renamed to match the corresponding release.
- Future planned breaking changes should go in SemVer-named milestones.
- All projects should have an "unscheduled" milestone.
- Issues in "unscheduled" are things that core developers and maintainers cannot make time to address.
- Use the standard GitHub labels.
- For repositories with multiple components (e.g., imagej-ui-swing) add "component:XXXX" labels, in orange, as needed.
- Every issue must belong to a milestone.
- Use the "unscheduled" milestone for inactive issues.
- If you are currently working on an issue, assign it to yourself.
- All issues in near-term milestones should have an assignee.
Using these conventions gives rise to a workflow where new issues come in with no assignee and no milestone, and the project maintainers either assign them to a developer who will carry out the work, or put the issue in "unscheduled" with no assignee.
Note that the relationship between milestones and software releases can be one-to-many: e.g., bug-fix releases, or even the addition of new features, may not necessitate their own milestones. Good milestone structure should read similarly to a good git history: informative without being overly verbose.
ImageJ has a Jenkins server, which automatically checks the code for build and test errors.
You can access Jenkins's last successful build artifacts from the Downloads page.
- News about ImageJ and Fiji developments, including status updates, observations and comments about ImageJ programming.
- Recent changes to this web site (not the ImageJ code itself).
- BugZilla database of user-reported bugs from the Report a Bug plugin.