Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

stable release 5.0.0 #1423

Closed
dvzrv opened this issue Apr 10, 2020 · 2 comments
Closed

stable release 5.0.0 #1423

dvzrv opened this issue Apr 10, 2020 · 2 comments
Assignees

Comments

@dvzrv
Copy link

dvzrv commented Apr 10, 2020

What problem will this solve?
When trying to package https://github.com/surge-synthesizer/surge for Arch Linux I realized, that it (also) relies on premake5. However, premake5 has been in alpha since February 2015(!).
Due to our packaging guidelines I'm not able to bring premake5/ premake to the repositories.

This leads me (and other distributions) to either being unable to package software such as surge, or having to introduce hacks, that require a lot more work.

Given the very long time premake has spent in alpha, wouldn't it be possible to tag a stable release?
I can't find any unresolved milestones and am wondering whether there's anything that would block a stable release.

What might be a solution?

git tag -s 5.0.0

What other alternatives have you already considered?
Building a local package of premake and generating the Makefiles required for building surge.
However, this introduces a lot of additional overhead.

Anything else we should know?

@starkos
Copy link
Member

starkos commented Apr 11, 2020

I understand your predicament.

@samsinsane and I have discussed this in the past. The problem with declaring a stable release is that we'll then be expected to keep Premake stable, and that just doesn't seem feasible currently. At a minimum, the Gmake/Gmake2 situation needs to be sorted, the Xcode exporter needs to be made fit for use, both Gmake & Xcode need to be made module-friendly, and the toolset abstractions need to be reworked to support more real-world setups. The internal APIs really should be cleaned up and naming conventions standardized for module developers.

It's a big job and I work on it as I can (h/t to our wonderful sponsors, without whom I wouldn't be able to work on it at all). Help is always appreciated!

I'm going to add @samsinsane to this issue and mark it closed for now. @samsinsane—feel free to reopen if you disagree with my summary above, or if your thinking has changed since then. And everyone else feel free to continue discussing here: I'll continue to get notifications and can reopen it if a case can be made.

@starkos
Copy link
Member

starkos commented Apr 27, 2020

In case you don't follow @premakeapp, I talked about this a little bit more in the most recent community update. Feedback welcome!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants