How to mark releases as pre-releases?

, ,
1

I see two apps, which accidentally released pre-release versions as stable versions on F-Droid (so they updated despite having “show pre-release versions” unchecked in the F-Droid settings).

These are:

  • Silence using a -unstable suffix
  • StreetComplete using GitHub’s feature to mark releases as “pre-release” but with “usual” version numbers

Both apps got updated, which is not expected.

So how can a developer correctly mark/tag a release as a pre-release, so F-Droid does not present it to all users?

BTW, maybe you can include the question/answer in the FAQ.

2 Likes
2

Does anyone have an idea?

3

I think because they added new tag(s) and the tags were “correct”.
So the automatic build was started…

v2.1, v2.0…

They should adapt the tags and make it “incorrect” for automatic build when it’s a pre-release.

4

Really? That looks like a hackish solution… Also what exactly are invalid tags?

5

Tag not like:
v {{ major }}.{{ minor }}

Check the specifications to know what is a valid tag.

6

Which spec?

According to semantic versioning a version like v1.0-beta is also valid. It is a pre-release of course. The -beta prefix is, according to semantic versioning, however, optional. So well…

My question could also be: Does F-Droid recognize such prefixes (as in v1.0-beta) as pre-releases?

1 Like
7

Rem: I’m not expert on Fdroid, just what I saw on topics of Gitlab by their devs.
It’s just an example what I posted, but check the link of my first post.
The semantic versioning document is not related to Fdroid :wink:

8

The only thing I read there is:

We try to build only what you would consider to be releases. These should have matching version names and, more importantly, matching version codes to releases you build yourself, and be built from the same code. Obviously this task is easier if your source code history is clear - for example, if releases are tagged or otherwise labeled. If you tag release, please ensure you keep the same tagging scheme, e.g. if you start using a “v” prefix, keep using that.

That does not answer the question of pre-releases however.

Is not there an F-Droid dev, which can answer it? It should not be that hard and I thought this forum was intended for such question. So why do two community members have to guess here instead of getting a straight answer?

9

While I left F-Droid some month ago, I still get Cc of the forum posts, the
issue tickets and mail inquiries. So let me try to explain this:

Yes, such question should be a nowbrainer to answer. However, for a
small mostly volunteer driven project like F-Droid, free/dev time is a
rather scarce resource. I’d assume that most devs have a schedule in
mind on what they want to work on, when they have time. That includes
what and when to check for “new” issues or posts. Unfortunately, most
of the time you don’t even get there, because you get stuck on a
problem before you reach the “end” of your todo list. So it’s not
that the question is hard to answer or devs are ignoring it on purpose,
they just dont have enough time to read through all the incomming
stuff… one of the reasons i was in favor to keep the forum minimal
back in my days, and move everything dev related to gitlab and irc:
move community to where development happens, causing less friction,
not cluttering on too many places… and maybe getting the community
to be more aware of what is being worked on.

Anyway, in regards to your question:

Android doesn’t care about version names, beta or release builds. The
only thing Android knows is the version code, an integer value. If its
higher, its an update. F-Droid honors this. It’s update checker tries
to find the “current version code”. Every build of the app it has with
a lower version code is an old release, if it matches the current one,
its, well, the current release and if a build app has a higher version
code than the detected current version code, this build is a
pre-release one.

You can fine tune what is considered the “current” version code by
sending merge request against your metadatafile in
F-Droid / Data · GitLab – e.g. setting a regex for
which tags to check or to ignore.

Note: Back in my days, only one check was performed. So you couldn’t
have something like auto-updates for releases and for beta builds. You
had to set it up for automatic updates for release builds and then add
betas manually.

For information on the metadata files, see the documentatin at
Build Metadata Reference | F-Droid - Free and Open Source Android App Repository .

10

Hi @anon25111075,

Maybe a solution is to work on a branch for pre-release and when it’s pushed to master (with change to the manifest) we can say it’s a release and FDroid will detect it and create the update :slight_smile:

6qEWk
6qEWk914×800 123 KB

11

Thanks for your reply and I understand that time is sparse for the devs, but I think this is an important question and may then just be put into the FAQ, so no one asks it again…

Regarding the explanation thereafter I still have no idea, how to mark pre-releases. Back in your time things seem to be different, because when looking over the link at the end there are several update mechanism…

@hotlittlewhitedog No, that’s rather a workaround. In git you develop on the master branch. Using some other branch for stable releases is not how it is intended – that’s what git tags are for.

Particularly one may look at the tag one – as this is the only one triggering automatic updates AFAIK. There something interesting:

It shouldn’t be used if the developers like to tag unstable versions or are known to forget to tag releases. [But: …] Optionally append a regex pattern at the end - separated with a space - to only check the tags matching said pattern. Useful when apps tag non-release versions such as X.X-alpha, so you can filter them out with something like .*[0-9]$ which requires tag names to end with a digit.

I think that may work.

1 Like