Costs to Expect API v2.04.0 in development

House decorating continues, we expect to be finished sometime within the next two weeks. Decorating is limiting my development time; as such, I have decided it would be a bad idea to release v2.03.0.

If I release v2.03.0 now, it will probably be two weeks before v2.04.0 is ready. These releases are interim releases, combined they complete a significant feature. A two-week gap between the versions could cause issues so I’m releasing v2.03.0 internally and will make another public release when v2.04.0 is ready.

We aren’t due to start another round of decorating until February 2020, so typical development cadence should return in November.

v2.03.0 of the API is on the way.

The development of v2.03.0 is almost complete; I expect to have it out before the end of the week.

For this release, I am refactoring the multiple item types code. Adding support for simple expenses increased the item code significantly. New item types are due to be added to the API, so it makes sense to refactor before the complexity increases additionally.

We are decorating our house, and the scope of our plans increased, there is going to be a negative impact on my development time.

Although the pace of development has slowed, it is going to pay dividends in the future. I expect the pace to speed up once we complete decorating and I have pushed out v2.04.0 of the API.

The release is too big!

It isn’t unusual for me to release at least one new update a week for the Costs to Expect API and website. I find it significantly easier to manage and test with small iterative releases. As the only developer on this project, anything that makes my life simpler is a plus.

Occasionally a release has to touch a substantial part of the Costs to Expect API, v2.02.0 is an example of that. I need to review every section of code relating to items.

I intended to split the development work for multiple item types across two versions, v2.00.0 and v2.02.0. The database gets upgraded, and then I hit the code and expose the feature.

In planning, I appear to have overlooked summary routes. Rather than extend the design I developed to incorporate item summary routes; it makes sense to modify it slightly, given the ‘new’ requirements. If I soldiered on and upgraded the item summary routes, I suspect I would want to refactor them in a few weeks. Rather than face that situation, I feel it makes sense to go back to the drawing board and ensure I develop a design that will work going forward.

Post-release of v2.02.0, I will rework the current design, refactor as necessary and then add support for multiple item types to the item summary routes.

I gave myself one to two weeks to develop support for multiple item types. It turns out, two weeks is probably about right given the increased (actual) scope.