search

alan-turing-institute / AssurancePlatform

Project to facilitate creation of Assurance Cases
MIT License
22 stars 6 forks source link

[meta] Setup releases for repository #398

Open chrisdburr opened 7 months ago

chrisdburr commented 7 months ago

We should have an option to label different versions of our app on GitHub, which is consistent with our documentation and DockerHub.

https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases

This will also allow us to setup proper citations for our repository: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-citation-files

kallewesterling commented 4 months ago

@chrisdburr @cptanalatriste We would need to define when we've hit a new version, which I'm very interested in hearing your opinions on. In my simplified view, these are our options:

(a) requires us to look a little bit ahead, and set up milestones for whenever we've accomplished this-or-that issue, we release a major/minor release, or

(b) we need to think a bit more about how we do this in an agile way, i.e. one suggestion is that when we deploy a version to the production site, it's a version change (1.0(.0)). Then, with bug fixes, we'd have smaller versions (1.0.1, 1.0.2), and simultaneously, in the dev branch we'd be working on 1.1, until we decide to begin work on any version that would be breaking logic with the previous version and thus would trigger a 2.0.

Happy for you both to add or change direction here!

chrisdburr commented 4 months ago

I don't have strong preferences on this, so happy to go with whatever you both deem "best practice" based on existing standards.

However, I would suggest that in the meantime we update the project README, the documentation, and the homepage to state that the platform is available as a "Research Preview" and that user should expect breaking changes and not store sensitive information anywhere.

kallewesterling commented 4 months ago

Sounds good.

chrisdburr commented 4 months ago

Minor amend to all of the above:

"The Trustworthy and Ethical Assurance platform is currently available as a 'Research Preview'. You should therefore expect breaking changes and ensure that you do not store any sensitive information anywhere on the system in its current state."

Then, perhaps worth directing people to the project board if they're interested in seeing the roadmap. This can just be in the README.

cptanalatriste commented 2 weeks ago

We have adopted [Hash Versioning] for the two artefacts of the platform: the docker images turingassuranceplatform/eap_backend and turingassuranceplatform/eap_frontend.

Every time we merge into develop and main branch, we create a new version of each artifact that is stored in DockerHub. At the moment, the latest version of turingassuranceplatform/eap_frontend is 2024-09-17.5b8f31a and for eap_backend is 2024-09-17.540432e

chrisdburr commented 2 weeks ago

Great. Thanks for getting this done, @cptanalatriste. Is there anything we need to do now to ensure that new releases are accompanied by something like a changelog? Or does this happen automatically from the commit log?

cptanalatriste commented 1 week ago

@chrisdburr at the moment, we do not have a changelog attached to each release. However, It's possible to build it from commit messages (keeping in mind the quality of the messages used so far). I would suggest creating a new issue for implementing a changelog if needed (although I suspect major edits will be required, given that some commit messages are not descriptive enough).

We will also need to, again, think about the audience for these notes: Are they developers, tweaking with TEA code? Are they end-users, only focussed on features? Both?

chrisdburr commented 1 week ago

That's fine. Thanks, @cptanalatriste. This isn't a high priority. Just wanted to check. Please could you close this and open a new issue for the changelog steps you've suggested.