From ImageJ
(Redirected from Project Management)
Jump to: navigation, search
Development
Overview
Topics
Philosophy
Governance
Licensing
Architecture
Versioning
Extensibility
Source code
Project management
Releases
Debugging
Hacking the source
Intro to Maven
Maven FAQ
Using Eclipse
Using NetBeans
Using IntelliJ IDEA
On the command line
Using native libraries
Coding style
Logging
Developing plugins
Writing plugins
Contributing to a plugin
Adding new formats
Distributing your plugins
Using Git
Overview
Git for dummies
Git mini howto
Git workshop
Git Conflicts
Git topic branches
Git Notes
Git reflogs
Git submodule tutorial
Pinpoint regressions with Git
How to publish a Git repository
How to extract a subproject
GitHub Tricks
Fiji
Building Fiji from source
Developing Fiji
Fiji + Eclipse
Contribution requirements
Supported compilers


The ImageJ and related SciJava projects take advantage of several project management tools.

Git

ImageJ uses the Git revision control system to manage its source code.

See the Git pages for more information, tutorials, etc.

Maven

ImageJ uses Maven for its project infrastructure.

SciJava projects use the ImageJ Maven repository (using Sonatype Nexus) for managing SciJava libraries. Such a repository serves two main purposes:

  1. Deployment. It provides a place to store our JAR artifacts, including snapshot versions, without the red tape of submitting to the central Maven repository.
  2. Proxying. It acts as an on-demand mirror for the public Maven repositories, reducing load on the central Maven server and potentially reducing local build times.

The first purpose is especially important for agile development across multiple components. For more details, see Reasons to Use a Repository Manager.

Releases are versioned with Semantic Versioning.

Continuous integration

ImageJ has a Jenkins server, which automatically checks the code for build and test errors.

Jenkins tests builds and performs releases for SciJava projects. It deploys SNAPSHOT builds to the ImageJ Maven repository in response to pushes to each code repository's master branch. So any downstream projects depending on a version of LATEST for a given component will match the last successful Jenkins build—i.e., the latest code on master.

Because every build also runs the associated unit tests, Jenkins is instrumental in early detection of new bugs introduced to the codebase.

You can access Jenkins's last successful build artifacts from the Downloads page.

Jenkins also performs releases, including automatically deploying ImageJ 1.x and building installers for ImageJ 1.x.

Jenkins performs many other services too, such as keeping Git repository mirrors in sync, building javadocs and updating other web resources.

Issue tracking

Tip: You can search for existing issues at http://search.imagej.net/ using the GitHub button!

SciJava software projects manage tasks and priorities using GitHub Issues:

Logo Project Issues Milestones
Scijava-icon.png SciJava
Imagej2-icon.png ImageJ
Imglib2-icon.png ImgLib2
Scifio-icon.png SCIFIO
Fiji-icon.png Fiji
BigDataViewer -
TrakEM2 -
Slim-curve-icon.png SLIM Curve
Loci-logo.png LOCI

Previously, some projects used Trac for issue tracking and roadmapping, but all Trac issues are now being migrated to GitHub. See these links:

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:

Who What How?
Users
want...
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).
Developers
want...
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.
Maintainers
want...
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:

Milestones

  • For short-term active development, use names m1, m2, etc.
    • These milestones themselves have no due date and never close, and contain only open issues
    • When an issue is closed, it is moved to match its corresponding release milestone.
  • 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.

Issues

  • 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.

As issues are closed, they are sorted into milestones which match each project's release tags, making it easy to browse which issues were addressed as part of each release.

The high-level topics of interest (i.e., bugs and enhancements) can easily be filtered by label, while milestones establish the timeline and functional development.

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.

Patch submissions

The preferred mechanism to contribute improvements to ImageJ and other SciJava components is using GitHub pull requests! See the Contributing page for details.

Roadmap links

  • 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.

See also

  • The Releases page, for more about how these resources are used to release SciJava software artifacts.