We create issues for all implementation work and generally for analysis work as well. (Other work such as consultations, meetings, e-mails, professional discussions are not tracked, obviously, so it’s important to note that time spent on issues is not expected to add up to the seven-hour workday.) Issues help us track and prioritize work that needs to be done as well as features we may or may not tackle in the future.
Our policy on releases, release numbering, and versioning is based on semantic versioning and the Python packaging guidelines. For details on how this policy came to be, please visit our blog post on the subject.
In a recent client project, we needed to mirror a specific subdirectory from our GitLab monorepo to a GitHub repository–complete with version history. This article explains why we chose Git Subtree over simpler approaches, the challenges we encountered, and how we implemented a mirroring solution in our CI pipeline.
Lately we’ve been discussing project versions and tagging for both releases and packaging. This has come up for tags on container images, and we also have developed a couple of Python libraries which we may want to publish to a public repository. While tags on container images have fairly relaxed restrictions, the Python Package Index for example follows a very prescriptive specification for versioning, and ideally we can find a solution that will work for both and is reasonably meaningful and intuitive.