Introduction to the Development Cycle
This section outlines the development cycle used by the BHoM Community in preparing, producing, and delivering the BHoM package to the world.
Milestones
Our development cycle works to delivery milestones - where the end of each milestone we release a new beta product of our codebase. These milestones are divided into the year by the DevOps team and aims to provide regular releases to the world that can be depended upon. Because the majority of our tools are delivered for the AEC industry, which relies on solid tools to perform their work, we aim to ensure our deployments are regular enough to be depended upon, but not so often that they might not contain robust changes that people can track. Thus, we develop in milestone cycles.
Currently 1 milestone is 12 weeks long, with 4 milestones per calendar year. The astute among you will know that 4 * 12 is 48 weeks and not 52 as a traditional calendar year contains. The remaining 4 weeks are divided up across the year to provide planning weeks between milestones, and allow for downtime between milestones. We are aware of the risk of continuous cycles of development within our community, and the risk that poses to burn out and other adverse mental health effects on our community. Therefore we aim to deliberately place blocks of time when we are not activiely developing to our code base (unless individuals personally wish to) and instead taking time to reflect, plan, and regroup before tackling another milestone. We encourage our community members to have breaks (for themselves (it's always good to have a holiday!), and for their mental/physical health) as they find appropriate, but we have also realised we can support the culture of taking rest time by encoding it into our development cycles.
Each milestone is referred to by 2 numbers, in an x.y format. The x number refers to the major year we are developing for. You can therefore identify the year a development occurred by this number, and the table below gives a reference of historic milestone years. The y number refers to the sub-milestone within the calendar year we are developing for, therefore allowing us to identify the quarter in which development took place.
As a development community, we are always developing one milestone in advance of what the end-users might be seeing. The end of each milestone becomes our beta release for that quarter, so the development community is always working for 12 weeks on a milestone to culminate in its delivery. This might cause some confusion, because the x.0 milestone is typically October-December of a given year, and not January-March as some might expect (as the first milestone of the major year). However, when you see that the x.0 beta is delivered at the end of December/early January to the world, it makes more sense (hopefully) - the users get to start the year on version x.0.
Once one milestone is over and the beta is produced (in line with our end of milestone procedures), we move into the next milestone. See our Operating Procedures for more information on what occurs at the start and end of a milestone.
Sprints
Each milestone is broken up into 6 development sprints, with each sprint lasting 2 weeks. This is longer than traditional software development sprints, but accounts for our community being mostly voluntary, with members typically working in the AEC industry and delivering projects alongside contributing to our community. Therefore, we don't want to push too much pressure on our development community to try to deliver enhancements to our tools on a weekly basis when things could quickly become stressful by unexpected life events! Thus, we conduct fortnightly sprints.
Each sprint comprises 2 calendar weeks from a Monday to the Sunday 14 days later.
Each sprint can have its own objectives depending on the team. For example, the DevOps team regularly chunk sprints into sprints that focus on our procedures, or on our bots, or on other aspects of our workload. This makes it easier for everyone to keep track of what's going on. Other teams just do development with no fixed objective other than to meet their milestone goals, and that's perfectly ok too - each team is different and we all contribute in different ways.
The numbering of the sprints is from 1-6 inclusive (for human readability as opposed to computing 0-5 readability). Where a planning sprint may be placed, this will be referred to either as Planning Sprint or sprint 0 if absolutely necessary.
The final sprint of the milestone is typically reserved for bug fixing, compliance issues, and preparing for the release of the beta for that milestone.
Discussion
As always, we welcome discussion on our calendars if you have any suggestions or queries!
Historic Milestones
All betas listed here were released at the end of their span.
| Milestone | Year | Span |
|---|---|---|
| 2.3 | 2019 | July - September |
| 3.0 | 2019 | September - December |
| 3.1 | 2020 | January - March |
| 3.2 | 2020 | April - June |
| 3.3 | 2020 | July - September |
| 4.0 | 2020 | September - December |
| 4.1 | 2021 | January - March |
| 4.2 | 2021 | April - June |
| 4.3 | 2021 | July - September |
| 5.0 | 2021 | September - December |
| 5.1 | 2022 | January - March |
| 5.2 | 2022 | April - June |
| 5.3 | 2022 | July - September |
| 6.0 | 2022 | September - December |
| 6.1 | 2023 | January - March |
| 6.2 | 2023 | April - June |
| 6.3 | 2023 | July - September |
| 7.0 | 2023 | September - December |