Looking for long-term collaborators for 1.0.0

[Cobrand]

Hi everyone,

as you may have noticed, I have been allowed to maintain this crate in AngryLawyer's stead for a year now, and while I love contributing to this crate, I can feel that lately my contributions couldn't follow with what everyone expects this crate to do.

Here is the goal: release a stable 1.0.0 version as soon as possible so that real projects can use this crate without fearing that everything will break from one month to another. I feel this is a requirement if we want this crate to be taken seriously. At the current pace this crate has, I cannot do this alone fast enough.

That is why I am looking for at least one long-term collaborator until 1.0.0 is finished. We have tons of things to do before 1.0.0, including finishing sdl2_gfx, overhauling sdl2_mixer (and sdl2::music) because their API is very awkward, and most importantly tons of documentation for uses with other platforms/crates/things, that includes:

• The crate gfx-rs
• An example of a very basic game with raw OpenGL calls for graphics instead of Canvas
• An example with a Vulkan integration
• How to use the lib from A to Z on Android
• How to use the lib from A to Z on iOS

I'm probably missing a ton more.

You can answer to this issue or email me if you are interested in helping, I'm grateful in advance!

[flukejones]

I've contributed a small amount in the past - so it's been a fairly long time since I've used this crate.. But, it's coming up to end of the university year and I may have some free time for a few months, which means I may be able to contribute once again.

How long is long term for you?

[Cobrand]

@Luke-Nukem appreciate it!

As I said, I'm looking for someone to assist me until it's done, so I think 6months to 1 year would be a pretty good estimate of what's to come, but of course it depends on the rhythm we're going to have.

[juliohq]

@Cobrand what about adding some helper functions like I did in #1293 and #1294? Would it be something that is on the 1.0.0 roadmap?

[Cobrand]

@Cobrand what about adding some helper functions like I did in #1293 and #1294? Would it be something that is on the 1.0.0 roadmap?

This thread is 5 years old, and despite that no one has volunteered; I'm still alone "maintaining" with big quotes. No more active dev is being done, and I struggle even to keep up with PRs nowadays.

So your PRs will be merged at some point, but a 1.0.0 is definitely not is the works now, especially now that sdl3 has been announced.

[tpstevens]

Is there a place to discuss current status and future plans? It looks like SDL3 is still a little ways out, and I'm curious about the future of this project. Some questions:

• Do you plan to add support for SDL 2.0.28+?
• What are your thoughts on eventually supporting SDL 3? Or are you more inclined to leave that up to https://github.com/revmischa/sdl3-rs, etc.
• In general, are you still looking for contributors? If so, do you need the most support with bugfixes, active development, etc?

I looked for your email but couldn't find it. Feel free to reach out to me at tyler.stevens.dev@protonmail.com as well.

[Cobrand]

Do you plan to add support for SDL 2.0.28+?

I'm planning to keep support to the most up to date version of SDL2, even beyond 2.0.28

What are your thoughts on eventually supporting SDL 3? Or are you more inclined to leave that up to https://github.com/revmischa/sdl3-rs, etc.

I haven't looked on how much work would be required to migrate this crate from SDL2 to SDL3, but I don't think it's undoable from what I have seen. 95% of the calls are the same, aside from a few core components. A fork of this project might be a good idea, or something behind a feature gate like what neon (the nodejs+rust binding crate) does is also a possibility.

The project you linked seems to be a fork of SDL2 from 2 years ago, so I think it's a real possibility to just do one of those. Doing a ground up rewrite doesn't seem like a good idea.

In general, are you still looking for contributors? If so, do you need the most support with bugfixes, active development, etc?

A 1.0.0 is now out of the question because I realized that locking most APIs behind a 1.0.0 would severely limit our options, especially given that most of the releases we do have breaking changes. However, I'm still looking for passive contributors as in "have a look at the PRs and read them" or "fix the CI pipeline when it's broken", etc.

For everything doc related I have given up, it would be obviously ideal but I don't have the time to do it and no one is really stepping up. As you can see this post is 7 years old and no one has really commited for the long term.

I looked for your email but couldn't find it. Feel free to reach out to me at tyler.stevens.dev@protonmail.com as well.

You can find my email in my commit details of this repository, I merge all of the stuff so you'll find me quickly.

[tpstevens]

The project you linked seems to be a fork of SDL2 from 2 years ago, so I think it's a real possibility to just do one of those. Doing a ground up rewrite doesn't seem like a good idea.

Agreed . That's primarily why I've asked here instead of in the project I linked to -- in Sam and Ryan's GDC talk (starting around 20:08), they call out that they synchronized some changes across the SDL2 and SDL3 branches and avoided making some desirable (but optional) changes to SDL3 for the sake of easily porting bugfixes between the two.

If you expect ongoing Rust-SDL2 changes, it could be worth synchronizing them with a future SDL3 crate or feature of this crate. And sure, it's possible to port changes between forks, but there's some extra latency there if the same team isn't maintaining both. Just curious if you had plans to do so and if you wanted support.

However, I'm still looking for passive contributors as in "have a look at the PRs and read them" or "fix the CI pipeline when it's broken", etc.

Thanks, I'll start there.

You can find my email in my commit details of this repository, I merge all of the stuff so you'll find me quickly.

🤦 Ah, of course. Github's interface doesn't show that by default (but it turns out you can show all details by appending ".patch" to a commit's URL), and in my coffee-less state I forgot that emails are present on, I don't know, every single commit ever made.

[Cobrand]

Ok so I have read a bit about SDL3, and there are some important changes to a few modules like rendering and audio, and some enum/structs are renamed, but the "core" should feel the same for now.

The most important thing that I'm reading though, is that SDL3 is not yet "released", as in SDL2 is still the one being displayed on the main page of SDL2. Until it's properly released, I don't think there is much value in supporting SDL3 for now, because we can expect still a lot of breaking changes until then.

Once we have a stable SDL3 and it's being publicly available for production projects, then we can have that talk.

[jgcodes2020]

Ok so I have read a bit about SDL3, and there are some important changes to a few modules like rendering and audio, and some enum/structs are renamed, but the "core" should feel the same for now.

The most important thing that I'm reading though, is that SDL3 is not yet "released", as in SDL2 is still the one being displayed on the main page of SDL2. Until it's properly released, I don't think there is much value in supporting SDL3 for now, because we can expect still a lot of breaking changes until then.

Once we have a stable SDL3 and it's being publicly available for production projects, then we can have that talk.

Speaking of which... that just happened.