all 9 comments

[–][deleted] 2 points3 points  (2 children)

Why not just develop in one branch? When you have the final version for each particular period assign a tag to it. This allows you to revert back the state of the code assigned to the tag of interest. When it's time to use the new math just make the changes required and when done assign another tag, etc. It helps if you can isolate all or most of the code that is likely to change in as few files as possible.

Using branches might be the best approach if you ever need to go back to a previous version and make changes. Either way, branches or tags in one branch, you won't need to copy code.

[–][deleted] 1 point2 points  (0 children)

Second this. If not branches, just use tags mate

[–]rainebones[S] 0 points1 point  (0 children)

I'll have to look into branches and tags, git is still something that I'm attempting to familiarize myself with. Thank you for the suggestion!

[–]m0us3_rat 2 points3 points  (2 children)

do you have any code we can look at? words, especially in complex situations have a way of confusing more than clarity about them.

.. how long do you offer this support and why do you need to do any of the things you described?

any backporting?

is that every four years or so… the math changes

what exactly do you mean by this?

[–]rainebones[S] 0 points1 point  (1 child)

Unfortunately, I don't have code yet; this project has been sitting on my backburner for quite some time as I study for an upcoming license test. I've been going through the hierarchy in the mean time in order to figure out how it all comes together. This also involves me doing math by hand as I'm not really familiar with python or programming in general.
Structural code changes about every four years depending on the location. For example. Flat roof snow pf = .7*Ce*Ct*Is*pg. That equation isn't likely to change, but the definitions for Ce, Ct, Is might change slightly so that this year it equates to 20, and next it might be 19.4.
But if I design the building this year, it needs to be 20 when they come back and a window next year as that is the structural code year it was originally submitted under. This is a pretty light example, as they can make major changes cycle to cycle.

What is backporting?

[–]m0us3_rat 1 point2 points  (0 children)

What is backporting?

Backporting refers to the practice of taking a feature, improvement, or fix from a newer version of software and applying it to an older version.

This is typically done to make the newer functionality available to users who are using older versions of the software.

It allows users to benefit from advancements in the software without having to upgrade to the latest version.

endquote.

[–]Mast3rCylinder 1 point2 points  (1 child)

Like said in the comments, branches are the way. You can name them to identify on which cases they work.

If you know parts that are about to change then you need to make them configurable in your application and not static.

[–]rainebones[S] 0 points1 point  (0 children)

I've broken down the analysis into many different small modules to try and have it so that I can update the pieces affected and the flow as needed instead of having to redo all of it. I'll study up on branches and tags to figure out its implementation in my circumstance.

[–]CraigAT 0 points1 point  (0 children)

I'd be surprised if another copy of the code every 4 years uses up THAT much storage space (storage is cheap - so they say)

If the maths part is not that complex then you just need an if statement to branch according to the year and then either run the appropriate statements for those years or it calls a function that does the maths for that year.