Next release schedule?



I was wondering when the next release of GLFW is planned for? There are a whole bunch of features merged into master that I would like to use in my application, but cannot until the next glfw release. An incomplete list of such features:

  1. Transparency
  2. glfwRequestWindowAttention
  3. Support for X11 mouse selection copy/paste
  4. Detecting num lock key
  5. glfwInitHintString

My application is

Thank you for your great work.


GLFW is an open source project developed by volunteers in their spare time, so there are no planned deadlines as such, though @elmindreda may have a feel for when the milestone might be completed by. The 3.3 milestone is tracked here.

If you’re interested in particular features then the best thing to do would be to see if you’re able to add this functionality to GLFW and submit a pull request.


Note that some of the features you need may already be available from the github master branch, for example glfwRequestWindowAttention is already available in soure builds.


Umm I am saying that there are a bunch of features that have already been implemented in master (some of them with my help), but that I cannot use, because there has been no release of glfw that includes those features. The last gflw release was over a year ago. Since my appliaction depends on the system glfw libraries, I need an actual release of glfw.


Ah, sorry I misunderstood that part.

It’s possible to use non-system libraries, so if you need features which are already implemented you can already do that.


Of course, I can bundle my own private copy of glfw, but for obvious security/maintenance reasons, I’d prefer to avoid that. Which is why I am asking if there is any estimate of a release date. Is it likely in the next couple of months? Next couple of years? Never? I can decide whether or not to go down the bundling route accordingly.


I’m not sure what security reasons you’re referring too. Adding glfw as a submodule or subtree will involve some work, as will updating the code to version 3.3, but this is fairly trivial. GLFW is very lightweight so static linking or just compiling the code in your makefile is a reasonable approach. It’s possible the master branch current state may be less well tested than official releases, but so far I have not observed any real difference.

‘Minor’ (3.x) versions of GLFW have taken at least a year to develop, sometimes more. 3.3 is at 87% since 3.2.1 in Aug 2016, which might give you some feel for when it might be completed, though as I noted earlier this is an open source project developed by people in their spare time so development is not linearly continuous.


The security problem is having multiple copies of the same library on your system. It means that is there is a security error in a library, you then have to hope that every single application that bundles it updates its private copy, instead of just updating the single shared instance.

I’m not expecting development to be linear, as the maintainer of over a dozen widely used open source projects myself, I am intimately familiar with how it works. What I am asking for is a best-guess estimate for when the next release will happen. Typically such an estimate exists in the mind of the principal developer. I am asking that estimate be shared with me, so that I can plan how to move forward with my project that depends on glfw.


I’m aware you’re an experienced developer (calibre is wonderful, many thanks). Since this is a public forum I’m trying to answer questions in a way which can be read by other developers with potentially less experience of open source projects, my apologies for not putting in the time and effort to make that clear.

For security concerns GLFW has a very low attack surface and performs no IO. I think the most likely attack vectors which might affect GLFW would be malicious code distribution via a package manager or a maliciously installed shared library patch to the glfw .so, both of which would be avoided by static linking at the potential cost of any vulnerability in GLFW (which I’d rate as lower). However I understand your concern and wish to wait for the official release when available.

As mentioned above @elmindreda may be able to provide an estimate. For the benefit of readers unfamiliar with open source development they should read any such estimate as just that.


Unless something goes very wrong, I expect the release to happen in the next couple of months. It would have been out already but then Life™ happened, taking away several months worth of spare time. It seems I’ll have plenty of time from now on but I cannot promise anything.

This thread started in the middle of writing the issue below, which may give you a better sense of what’s going on. Please join in if you are able.

In the coming weeks I will need to catch up on and respond to many issues, but you should also see 3.3 features starting to be merged.


@elmindreda Thanks, that’s all I wanted to know. Take your time, there is no rush. I’ll help if I can. And once again, thanks for glfw, which is a joy to use :slight_smile:

@dougbinks No worries, it’s great that you help people on this forum – that is a very important part of making a software project successful in the long term. I would really rather not have to bundle glfw on linux, so I am happy to hear that 3.3 is on the horizon.


I’d echo what @dougbinks said about having your own copy of GLFW, though. Even after 3.3 has been released, it will likely take a very long time for all major distributions to update to it. GLFW also doesn’t touch the network, hardly ever touches the filesystem (and then only for reading) and doesn’t require privilege escalation (except minimally on Windows in order to receive drag and drop), so a critical security issue seems unlikely.

Edit: Of course, this is the worst possible day to make such claims.


kitty does not work on “major” distributions anyway, most of them dont even have glfw 3.2 or glew 2. I just want there to be a release I can say that kitty depends on – then its up to users/distro packagers on how to satisfy that dependency. And on macOS kitty bundles its own copy of all its dependencies. So once there is a glfw 3.3, I can write code in kitty that uses that, and it will work on modern linux systems and macs. I long ago decided that gating features based on what “major” distros do is a mug’s game.

Yeah as far as security goes its not filesystem access/network access that’s important, it’s memory issues.


Those do happen.


Indeed, thankfully we now have the ASan and UBSan tools to help with catching them :smile: