How to organise a code base for current version and long term support?

Torsten_B · 12 September 2023 07:10

Xojo’s transition from Web1 to Web2 with no IDE support for Web1 on more recent releases and the lack of bug fixes for the last revision that fully supports Web1 created a huge problem for developers maintaining an existing code base of Web1 software.
It appears that Xojo is unable to maintain Web1 coexisting with Web2 in the same code base.
Adoption to new versions of the host OS doesn’t happen and critical bug fixes are not applied. I observed a similar policy at FileMaker, where fixes are only applied to the new next shiny version but never to existing version, still in use with enterprise customers.

Microsoft, Apple provide critical bug fixes for OS version 2 major release numbers in the past (means 6 years and older). Vendors of Linux distros, databases, IDEs and many other tools provide LTS versions in lifecycles more in sync with industry needs.
Conclusion: Many vendors can and do provide long term support for their products while others don’t, be it because they technically can’t do or for commercial policy reasons.

How should a code base be structured and organised for development of the next version and maintenance of existing (LTS) versions?
What are the skills a team needs and what are the tools required for implementation and execution of an LTS policy?

npalardy · 12 September 2023 15:10

personally I’d have a branch for each major release

everything starts in a develop branch

when its beta tested & proven it gets merged to “master” or “main”

every release version then is a branch from “master”

this way you can isolate it for its duration as an LTS release

patches from “master” can be applied separately to each release branch

but dont forget that not only do you need to organize the code you need to also take care to preserve the development environments etc esp if those can change significantly or introduce new dependencies or other changes in their frameworks
VM’s, docker containers, etc all need to be preserved

TomasJ · 13 September 2023 05:03

Firstly git (or any other CVS) included in the IDE or at least toolchain (huh, Xojo is already out!)

Secondly use free and text-only formats for everything. Your documentation, your automation, your graphics (SVG).

Use free (in terms of GNU freedom) technology, what prevents you from any vendor lock-in-effects and “genius” CEOs.

But the most important advice: Try to reduce dependencies Keep your fingers off from NPM or any other crap where you basically lost control over your sources. Just this xkcd as reminder: