Track changes in the system

OCHA-DAP / hdx-signals

HDX Signals

https://un-ocha-centre-for-humanitarian.gitbook.io/hdx-signals/

GNU General Public License v3.0

5 stars 0 forks source link

Track changes in the system #77

Closed caldwellst closed 3 months ago

caldwellst commented 4 months ago

I think from public release onward, we should be tracking changes and improvements in the system, for ourselves and for the public. Some thoughts below:

Have a NEWS.md or CHANGES.md file.
Do we need tagged GitHub releases? Might be helpful for us, but since people are not using the repository directory not sure it will matter?
Is there a way to tag content in the NEWS.md file that will translate over to a different file for relevant public consumption? Like changes to plots or content that users might care about?
We have campaign generation date, but if we had tagged release, could add in the dataset a column for release version when signal was generated?

hannahker commented 4 months ago

Definitely support a tagged GitHub release! And I like the idea of associating that versioning with different campaigns. Although... 🤔 we're probably going to end up with a lot of releases if code is pushed to production anytime we merge to main. Might want to think about having a dev branch where we stage things? Although from experience, using a dev branch can make our workflows unnecessarily complex.

caldwellst commented 4 months ago

Yeah, @zackarno suggested a dev branch as well, but since we would only produce signals from a single branch main, not sure it's worth the hassle, unlike systems where it's like a codebase you can access either version of.

Maybe semantic versioning can work but x.y.z is only relevant for changes affecting external outputs? I guess issue is tracking significant changes to the system, but I guess that's fine if we just grow grow grow and have loads of versions ha. The HDX Python API seems to be on major version 6 lol, so we have precedent.

caldwellst commented 3 months ago

Closed by #146