The initial development work for v2.00.0 of the Costs to Expect API is almost complete. I’m just one dev session away from all 1200 Postman tests passing.
I used the word initial, the v2.00.0 branch works; however, the two core features are not going to be complete until a couple/few .01 releases after v2.00.0. The base v2 version is about getting the database ready and ensuring all the migrations are valid; it is a significant change to the v1 database.
Permitted users are pretty much complete, the API will be missing the management of users, but that will quickly appear in .01 release.
Multiple item types, this is the big one.
As mentioned above, the database work will be complete; I should be able to write simple migration files for all additional releases without affecting existing data. The code is a little bit of a clutz; I’m merely joining to the only known item type sub table.
Updating all queries with a join to the item_type_allocated_expense table works; however, the code isn’t dynamic. When additional item types get added, creating, deleting, sorting and searching will all fail.
Once I am happy with the initial v2.00.0 release, I will add permitted users management and then work out how I am going to refactor the code to support dynamic item types. I have several ideas; however, I need to come up with something scalable and going forward will work for what I have planned for v2, v3 and beyond.
I had planned the first (private) release of the Costs to Expect app to be in late September, given the additional work, I suspect it will now get bumped into October.
We should still have something ready for public consumption before the end of the year. We are experiencing a minor bump in the road; these issues aren’t anything I wasn’t going to have to work out anyway, I have to solve some interesting problems sooner rather than later.