search

vulkan-go / vulkan

Vulkan API bindings for Go programming language
MIT License
742 stars 55 forks source link

How to support more than one API version? #73

Open tomas-mraz opened 1 year ago

tomas-mraz commented 1 year ago

Hi Max and Randall, I would like to open the topic "maintain two major versions" to discuss. I mean for Vulkan 1.1 and 1.3. I dig around versioning schema a little bit. The tricky part is the heavy focus of Go on a module's major versions like v1 ... v2 ... v3 ... so the difference between 1.1 and 1.3 simply isn't enough. (I tried and end up with "has malformed module path")

1/ We can do the branch v1 for Vulkan 1.1 with tags v1.0.0+ and make master for Vulkan 1.3 with tags v3.0.0+. Import ...vulkan-go/vulkan get data by tags from "v1" branche. Import ...vulkan-go/vulkan/v3 get data by tags from master (as "v3" in case "v4" come).

2/ The second approach is to just add the directory "v3" in the existing module in the master branch. Make there a second go.mod with path ...vulkan-go/vulkan/v3. So import ...vulkan-go/vulkan is the same and import ...vulkan-go/vulkan/v3 actually means "path with folder v3". It is a little bit messy because all files are together and tags should be v1.0.0+ and v3.0.0+ in the same branch depending on changes to publics. It is a backward-compatible solution (in case some app can't handle branches).

These two solutions can't make "visible version" sync "module 1.3 -> Vulkan 1.3" (for example Vulkan 2.0 could be module v4) As long as I understand there are no publication changes without a tag (even "latest" just detects only the latest tag). So it looks like no more riding on the last commit :-)

3/ The alternative is "GOPATH mode" which seems like "no tags, all in one repo, just longer path in git and module's name" ... good old days.

Interesting sources ... https://go.dev/blog/v2-go-modules https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher

My personal preferences are, 1 the best ... 3 I can live with that ... 2 ohh noo I can't rule out that I didn't miss something.

xlab commented 1 year ago 
Import ...vulkan-go/vulkan get data by tags from "v1" branche.
Import ...vulkan-go/vulkan/v3 get data by tags from master (as "v3" in case "v4" come).

I see this as the only reasonable path forward, very compatible with current industry standards in Go :) The only thing to care about is compatibility between versions, I assume we can safely do following:

I assume it works since Vulkan 1.1.17 would be compatible with any 1.1.x other versions, 1.2.17 with 1.2.x etc.

Thanks for the suggestion!

tomas-mraz commented 1 year ago

@rcoreilly I checked Go version 1.10 (before the Go Modules system) and when you try ...

go get github.com/vulkan-go/vulkan go build

then Go take the master repository.

1/ When we

it will be a breaking change because projects running on Go1.10 get version v3 instead of (actual) v1.

2/ We can

Finally, after projects migrate to Go1.13+ can be master remove.

3/ or

A little bit confusing that the master does not contain the latest data.

4/ or

Well ... an unfriendly solution but effective.

neurlang commented 1 year ago

I vote for master, v3 for Vulkan 1.3, and v1 for Vulkan 1. It would be pretty unexpected to clone master and not have vulkan 1.3 on it (if master is the main branch). Thats why I don't like options 2/, 3/.

Regarding option 4/ making old Go unusable is not ok imo. Better make it broken by forcing latest master to old go.

Jorropo commented 7 months ago

You don't actually need to split branches, you can have a v3 sub-folder within the v1 master branch. Then everything exists in the same branch under different folders.

tomas-mraz commented 7 months ago

We definitely need v3 branch. Alex, can you create IT, please?

Jorropo commented 7 months ago

I meant to have the import path github.com/vulkan-go/vulkan/v3 you can have a v3 folder in the same branch the current code exists. This allows to have commits and PR which atomically modify both series (if let's say one depend on the other).

You maybe want different branches for organization purpose then yes multiple branches.