![]() |
Programming Versions - Printable Version +- Scivillage.com Casual Discussion Science Forum (https://www.scivillage.com) +-- Forum: Science (https://www.scivillage.com/forum-61.html) +--- Forum: Computer Sci., Programming & Intelligence (https://www.scivillage.com/forum-79.html) +--- Thread: Programming Versions (/thread-15005.html) |
Programming Versions - stryder - Nov 23, 2023 In programming any decent project will use a version structure, however the many different descriptions of how it's applied can appear archiac. I was pondering the nature of versions the otherday and came up with something that seems logical. Version (Major and Minor) reflect on whether a particular change to the version is using a Bottom-Up or Top-Down approach to programming. In the case of Major versions, the very core nature, the foundations on which something run (like an engine) are fundementally changed. That's because the design approach is Bottom-Up, emphasising logic, strategy and the scope of any and all design that is to be built upon it as a foundation. The Minor versions use a Top-Down approach, It allows for singular problems to be concentrated on from above and work around problems that might exist for the limitations of the foundation until a Major version corrects the disparity. Top-Down in some respects is a hacking method, it deals with a quick resolution of the problem but doesn't necessarily take into consideration the full plan of a build. It's where magic happens in regards to prototyping however it's also what leads mostly to instability and not being optimised. Minor versioning might well prototype the fixes (And include work around "patches") however ideally eventually they need to be broadened into the Major build. That implied if you had two teams working on a project, one could be dealing with the long term goal of making a stable foundation on which everything runs, while the other team pushes quick dirty patches and prototypes for new features. The team dealing with major patches could take a while to release a major patch, while the team handling the minor patches can push(release) them at far regular intervals. As to the version numbering itself, in some respects the value is suppose to be "Non-Fungible", however that could be difficult to fully apply as "How long is a piece of string?" (It's irregular in regards to how many edits are applied per patch and/or version) It would great to somehow apply where the minor versions are converted to the major version so you can tell which minor versions are outstanding in a major build etc. RE: Programming Versions - confused2 - Nov 23, 2023 Brilliant! Even my own small programming efforts are heading in the direction of chaos - I really need implement this now. Most of my patches or (sometimes) improvements are made to a library so one library becomes (say) v1.5 but the rest are unchanged .. to compile to a v1.5 program would be possible, it would even be possible (but tedious) to re-version the rest of the unchanged libraries.. any thoughts? I'm fairly sure when moving to a new 'bottom up' version all libraries should be re-versioned as compatible with the new version .. any thoughts? RE: Programming Versions - stryder - Nov 23, 2023 (Nov 23, 2023 09:33 PM)confused2 Wrote: Brilliant! Even my own small programming efforts are heading in the direction of chaos - I really need implement this now. Most of my patches or (sometimes) improvements are made to a library so one library becomes (say) v1.5 but the rest are unchanged .. to compile to a v1.5 program would be possible, it would even be possible (but tedious) to re-version the rest of the unchanged libraries.. any thoughts? I'm fairly sure when moving to a new 'bottom up' version all libraries should be re-versioned as compatible with the new version .. any thoughts? I was thinking along the lines of a mask system similar to unix systems chmod for access levels. The problem of course is creating something large enough to cover the evolution of a project, it might of course be possible with a high enough base(number of characters) and/or string length. That way when a minor patch is pushed to major, it would be like inverting the mask for that entry. I'm still trying to work out however if it would make sense trying to localise it to particular milestones rather than handling the whole revision system as the mask could get extremely large. |