Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

request to periodically make versioned tagged releases

Open
  • Is something wrong?
#166 1 comment 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 2 days

@gurchetansingh is already working on this.

Since Aug 3, 2026.

Assessment

This issue has not been assessed yet.

Description

  • Firstly, Thanks to gfxstream+magma+rutabaga team / Google for the opensource contribution
  • Just a user here.
  • The Linux distribution version of gfxstream seems to not have been updated in a long time.
  • The Fedora koji build [3] still seems to be using version 23d05703 [4] which dates back to 20231003 , which ATTOW is over 2 years old.
  • The hesitation might be that when manually looking at the commit logs as an outsider, one cannot know if any given commit version is stable enough to build with, and/or (very likely) that downstream builder scripts need an detectable upstream tag to automate building.
  • There seem to be bugs like mesa-15796 [5] which suspect version mismatch or outdated code. The existence of that issue is also evidence that there are Linux users / developers willing to try gfxstream out and try make it work.
  • Filing this issue to suggest to gfxstream team to make periodic versioned tagged releases so that downstream distributions catch up.
  • To users, the benefit of gfxstream on more platforms is that
    • allow for use cases of gpu acceleration where virtio-gpu is not available or does not work.
  • To gfxstream project, the benefit of periodic versioned releases is that
    • there will be more users of gfxstream testing out the code paths via gfxstream.
    • more security, plumbing and bit-copy bugs will get reported and fixed. hence making gfxstream more reliable for android also.
    • bugs will be reported on specific versions with known feature maturity
  • It is understandable that gfxstream may not want the maintainance burden of supporting Linux to high reliability, as it focuses on android. It is sufficient to
    • (1) make a just-able-to-initialize-and-use sanity version every now and then and let the Linux volunteers report or iron out the Linux bugs.
    • (2) make sure android-studio, mesa and qemu will build with that version
  • Perhaps one can make
    • lockstep version tagging that match with android-studio releases (ATTOW 2026.1.3.7)
      • perhaps use the same commit version that is used by the final released android-studio
    • or lockstep version tagging or that match with mesa (ATTOW 26.2) or qemu (ATTOW 11.1)
    • or independent periodic version tagging yy.mm like mesa or N.#n like qemu
  • As to the timing of the version tagged release, candidate times may be
    • at the same time as android-studio
    • or 2 months lead time (Jan Jul) before a Fedora-Workstation release (Apr Oct). Fedora usually picks up bleeding edge versions of packages The lead time is usually enough time to sort out build errors, before the publication of the Fedora Linux distro (6 monthly).
  • The version tag gives some idea of how old the code that is used to build the binary file of the gfxstream library, is.

Ref:

Dominant language
C++
Stars
60
Forks
41
Avg merge
1d 2h
Merged PRs (30d)
9

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from google/gfxstream

All issues in google/gfxstream

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.