Tag 19.2 is currently using DB schema version 136 but the master branch is using version 138.
Should the version of tt-rss be increased when there is a schema change? Or is this intentional?
I only ran into this since I was running my own docker instance based on master branch and then switched to using the linuxserver image: Docker
Any desire to keep the version and schema in line with each other?
It would be fairly easy to automate if you do, potentially with drone.io: https://docs.drone.io/server/provider/gogs/
I recall you were setting up tests at one point in time so this would help automate the testing as well.
This would also allow building and publishing an official Docker image.
I would like to help set any/all of this up if you are interested in the ideas.
there’s no connection between schema version and overall tt-rss version. schema version is bumped when there’s a schema update so that automatic updater could work, that’s it.
as for overall tt-rss version, i bump it from time to time but it’s largely arbitrarily. consider it a progress milestone which shows that some work has been done on git master, it doesn’t mean anything beyond that. it’s not a software “release” in a normal sense or anything like that. you absolutely shouldn’t stay on some git changeset just because it happened to be tagged.
also, re: automation, i’m not sure why would i use some hipster dot-io monstrosity with YML and docker to do a job better suited for a ten line perl script. unless of course plugging this website was an actual point of your post, tsk tsk.
there’s multiple docker images for tt-rss available already, i have no interest in maintaining an official one.
e: since this tag thing pops up from time to time, i’m thinking maybe “rolling release” wasn’t the best term for tt-rss development, so i’ve tried to clarify how this actually works here:
The only thing I would suggest is explicitly stating “Potential breaking changes are developed in a separate (i.e. not master) branch.” Just so there’s absolutely no confusion about the “safety” of using master.
e: Actually that makes it sound like any breaking change won’t be introduced into master. So maybe ignore me.
Understood that version numbers don’t imply more or less stability but it’s helpful to know when there will be a DB change so you easily know if you can roll back to a specific commit.
Trying to use an old schema version just results in a loop of tt-rss saying it’s up to date.
Also I’m not plugging that drone CI, just saw it integrated with Gogs, which… Gogs.io are you going to switch back to gitlab now?
you can track schema versions through git by base .sql files being updated.
that said, actual schema changes may be committed before or after base code changes which implement them. then those changesets are pushed together to public master branch.
each individual batch of changesets pushed to master may be considered a “release” in that (normally) master should be in a working coherent state after each push, unless of course i screw up somehow and break things. however, each batch may contain multiple changesets and going back to one of those arbitrarily may be unwise. at least, i never take into account someone doing so.
the tldr here is that i expect everyone who follow master to stay on latest changeset available at time of pull, with update interval being up to their discretion. if they want to do something else - stay on some tag or changeset or try to go back, as far as i’m concerned they are on their own.
tbh i would prefer to use bare git repositories without any bloatware UIs on top of them.
i only suffer gogs, weblate and whatnot to make it easier for other people to contribute.
are you going to switch back to gitlab now?