search

grosjo / fts-xapian

Dovecot FTS plugin based on Xapian
GNU Lesser General Public License v2.1
94 stars 20 forks source link

stability expectations of tagged releases #172

Open symphorien opened 1 day ago

symphorien commented 1 day ago

Hello,

As a downstream packager I usually assume that tagged releases are reasonably working snapshots of the code. However it seems that in response to github issues you push untested fixes to master, tag them, and then ask people to test them. Half the time the changelog is just "bug fixes" but you don't have the response yet of the people who you asked to test the patch, so you don't know if it's a bugfix yet.

So if I attempt to package the latest release, there is good chance I'm packaging untested patches with no good way for me to know that.

Is there a way to distinguish tagged releases which are actually tested to work somewhat, and those which are only untested patches to be tested by people affected by bugs?

This could either take the form of releases with a recognizable suffix like -beta, -rc1, -rc2 etc or even preferably, of using branches instead of master for untested changes.

Or should I only package x.y.0 releases because contrary to my unfounded expectations x.y.z releases are development releases?

What do you think?

grosjo commented 8 hours ago

Released version are to be used in production, but of course, there is always improvements