[Question] Tag and Release Policy / Strategy

[gotjoshua]

I see that the docker hub image is updated very regularly, but that there are no release tags since 2019, and no stable channel.

What is your policy and or strategy?

Are all commits to master considered stable?

Is there a way to find out which image you are running on your hosted offering?

[mickael-kerjean]

Are all commits to master considered stable?

The source of truth for a stable release is the CI: https://cloud.drone.io/mickael-kerjean/filestash Is considered stable a commit that is green in the CI pipeline. Master is stable 99.9% of the time

Is there a way to find out which image you are running on your hosted offering?

https://demo.filestash.app/about

I see that the docker hub image is updated very regularly, but that there are no release tags since 2019, and no stable channel.

I did tag for v0.1 -> v0.4, the decision when introducing v0.5 was not to create tag per say but to follow a different naming convention: v0.5.BUILD_DATE, right now the latest stable build is v0.5.20220527. Meaning the last stable release was made about a month ago (I've been quite busy with my newborn, hence the lower pace since last month). Such naming convention is unusual but it's been serving us well with pretty much no drawback yet

What is your policy and or strategy?

1. any commit that is available as a tag on docker is stable: https://hub.docker.com/r/machines/filestash/tags
2. any commit that has gone through the CI pipeline is considered stable (eg: https://cloud.drone.io/mickael-kerjean/filestash/392)
3. the running software will shows everything you need to know about it from /about, from the commit it was build from linking back to github itself, the date of the build, various hashes for security and the list of plugin it was built from
4. we will be staying in v0.5.XXX until a breaking change need to be introduce or when the software is 10 years old in 2027

[gotjoshua]

Such naming convention is unusual but it's been serving us well

fascinating!

we will be staying in v0.5.XXX until...

Okkkk... that means you have no aspirations for a milestone v1.0, with a notion of "feature complete enough for now"?

All the best with your newborn - hope you enjoy the journey of parenthood immensely!!

[mickael-kerjean]

Yes definitly but going 1.0 would mean the entire technical debt has been paid off. Things like:

• issues around mobile usability in the current frontend which was done for desktop first and slightly changed to accommodate the use of mobile. The support for phone should be better if we're to go 1.0
• update the frontend code to some more recent react version. At the moment we're stuck to an old release as we heavily rely on some libraries that make use of hooks that have become deprecated and there's no simple path forward
• the absence of tagging, we'd need to have some feature to easily tag things and find those back. I've been hitting the nail on that one for a long time but I finally got an approach that would work in the Filestash model (aka without central DB to talk to and without assuming you can write a file on the data storage to store that data). I'm just lacking the time to make this happen
• create more tests on the frontend. Hopefully we have a range of e2e that has caught a lot of issues but it would be much nicer to have everything with good unit / integration tests

Anyhow, there's a long path forward before Filestash can be made 1.0 and the only way this will happen is if I'm lucky enough to be able to work on this full time.

[mickael-kerjean]

I'm closing at I don't see any action on my side here. Feel free to comment back and I'll reopen if needed

[ThisGuyCodes]

I did tag for v0.1 -> v0.4, the decision when introducing v0.5 was not to create tag per say but to follow a different naming convention: v0.5.BUILD_DATE, right now the latest stable build is v0.5.20220527. Meaning the last stable release was made about a month ago (I've been quite busy with my newborn, hence the lower pace since last month). Such naming convention is unusual but it's been serving us well with pretty much no drawback yet

This does not actually appear to be the case? I can't find any tags matching this pattern in Dockerhub or Github, all I see are tags which match truncated commit hashes.

While strictly functional, this makes any sort of e.g. automatic updating difficult... the v0.5.BUILD_DATE however would be perfectly functional for this! Can you help me understand where this v0.5.BUILD_DATE pattern exists?