Raster Vision's newest release is from August 2024, and its meta-package points at wheel files in the source tree

The last release is twenty one months older than the last commit

Three releases are on record and the newest is v0.31.1, published on 2024-08-30, preceded by v0.31.0 in August 2024 and v0.30.1 in May of that year. The default branch was last pushed on 2026-06-04. So the repository is not abandoned, and it is also not released: everything done since that August is on a branch, and the packaging file describes the current tree as a development version one step past the last tag. The practical consequence is that a framework pinning its dependencies to exact versions resolved in 2024 is two years of upstream library movement away from the code in front of you. The documentation badge points at the stable documentation rather than the latest, which is the right choice for that situation and also confirms which of the two versions the page is describing.

The meta-package depends on wheels that live in the source tree

The install instruction is one line, and it is worth knowing what it resolves to:

pip install rastervision

The packaging file behind that command lists the project's own packages as dependencies, and every entry is a local file path with a placeholder for the project root in it:

"rastervision_pipeline @ file://${PROJECT_ROOT}/rastervision_pipeline/dist/rastervision_pipeline-0.31.2.dev0-py3-none-any.whl"

There is no step in that file that substitutes the placeholder, and the wheels in question only exist once each plugin has been built into its own dist directory. Meanwhile the declared dependency set is marked dynamic and sourced from a requirements input file, and the checked-in lock file says at the top that it was generated by a single compile command run across eight of the plugin manifests with each one excluded from the output. So the front page offers a one-line install and the machinery behind it assumes a local build has already happened. That is a normal shape for a monorepo and an awkward one for a package index.

Every system package in the image is pinned to an exact version

The container file takes three build arguments for the CUDA version, the Ubuntu version and the build type, and defines two build stages. Inside them, the system package installation pins every package to an exact distribution version, down to the patch level of wget, the compiler, the OpenGL library, curl, git, tree, the GDAL binaries and the GDAL development headers. It then installs Node 16 from a third-party repository, again at an exact version, and uses update-alternatives to make the requested Python version the default for both the versioned and unversioned interpreter names. Pinning that hard inside a base image selected by tag means the build succeeds on the day the tag points at a compatible image and fails as soon as that image's package index moves, which for an untagged base is a matter of when rather than if.

Nine packages, three of them for one cloud provider

The tree is nine plugin directories plus the meta-package. Two are the pipeline and the core, two are the PyTorch backend and the PyTorch learner, one is named for the GDAL virtual filesystem interface, and three are named for AWS: one for object storage, one for batch, one for the managed training service. So the plugin boundary is not arbitrary. It separates the parts of a geospatial workflow that are hard from the parts that are vendor specific, and the vendor specific parts happen to be AWS. The virtual filesystem package is the mechanism behind the library's claim about reading geo-referenced data without downloading everything first, which is the single most important capability for anyone working with satellite imagery at scale. It is also the least documented of the nine, because the page points at the documentation site rather than at any of the plugin directories.

Docker tags are commit hashes, not version numbers

Images are published to a container registry under the project's organisation, and the tagging scheme is described precisely. A new tag is published per merge into the default branch, named with the first seven characters of the commit hash. To get the newest one you pull a tag with a latest suffix, and the example given names a PyTorch variant of it. Git tags are also mirrored, using the tag name as the suffix. So there is no image tagged with a release number in the ordinary sense, no way to ask for the image that matches version 0.31.1 except by knowing its hash or its git tag, and a floating tag is the documented way to get the newest image. For a framework whose last release predates its last commit by twenty one months, that is a coherent choice and also one that removes the release as a reference point.

Two reader paths, six pipeline stages, one cloud

The usage section splits its audience in two, which is a good sign about how the project thinks about itself. People who are not deep learning experts are pointed at the framework as a low-code tool where the library handles the complexity and the user configures a few parameters, with the quickstart as the entry point. Developers who want to combine it with their own code get a usage overview, a page of basic concepts and a tutorial index instead. The pipeline the framework configures has six named stages in order: analyse the training data, create training chips, train the model, create predictions, evaluate the model, and bundle the model files with their configuration for deployment. The last stage is the one that tells you this is aimed at shipping a model rather than exploring a dataset. Cloud execution is offered through two AWS services and nothing else.

A contributor licence agreement on top of an Apache licence

The licence section is short: the project is under the Apache 2 licence, with the file in the repository root and a separate text file collecting the third party licences of everything it depends on. Two things sit alongside it. Everyone who contributes code is asked to sign a Contributor License Agreement, which is a grant-back style gate rather than the lighter certificate of origin model most Apache projects use, and it is the kind of thing a corporate contributor will need legal review for. The project also asks that larger features and design changes be discussed with the maintainers before the work starts, and describes that as making the acceptance process smoother. Around that, the repository carries three separate linting configurations for Python, a coverage configuration alongside a coverage service badge, a citation file, and a documentation build configuration.

Editorial conclusion

Raster Vision is a substantial piece of engineering and the shape of it, a plugin architecture with a low-code pipeline on top of PyTorch and geo-referenced output throughout, is a reasonable thing to adopt if your imagery work is serious. Two things decide it in practice. Dates, because the last release is twenty one months older than the last commit, so you are choosing between a frozen release and an unreleased branch, and the frozen one carries a lock file resolved in 2024. And packaging, because the meta-package's declared dependencies are wheel paths inside the source tree with a placeholder in them, which means the pip install on the front page and the dependency list behind it are not obviously the same artefact. If you take it on, pin a commit rather than a version, expect to build the plugin wheels yourself, and read the two cloud integrations as AWS-specific rather than cloud-generic. For anyone only exploring, the quickstart path and the published Docker image are the low-friction way in.

Frequently asked questions

Official sources

1. azavea/raster-vision on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases