Package versioning - Githubissues

discosultan / VulkanCore

Vulkan 1.0 graphics and compute API bindings for .NET Standard

MIT License

168 stars 27 forks source link

Package versioning #32

Open WardBenjamin opened 6 years ago

WardBenjamin commented 6 years ago

Right now, the library version is 1.0.0-alpha39. What's the reasoning behind having a semantic versioning format (v1.0.0) as well as the additional version indication?

Going forward, I'd like to stick to strict SemVer if possible, and everyone agrees that we should move towards that option:

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

WardBenjamin commented 6 years ago

Also, there needs to be a new package release version anyway since the public ctor for the SurfaceKhr was merged in.

discosultan commented 6 years ago

The original idea was to use the suffix until it's stable enough to release it as v1.0.0 and then move forward with semver. Obviously the project never reached that point. I agree that it should already follow semver. It should also be versioned in the v0.X.X range - at least until it's unstable and sees a lot of breaking changes. Otherwise we would be rushing through major versions like crazy.

If we were to move from v1.0.0-alphaX versioning to v0.X.X, that means that all the existing v1 packages in NuGet should be delisted. Which I'm totally fine doing.

Also, I've pushed the most recent version to NuGet (using the old versioning scheme).

WardBenjamin commented 6 years ago

Delisting the old packages works for me (thanks for pushing latest).

When would you consider it stable enough to release as v1.0.0? As-is, I've been pretty satisfied with the library as a whole - though we probably need documentation of some kind.

discosultan commented 6 years ago

Initially, there were ideas for major refactorings like https://github.com/discosultan/VulkanCore/issues/6. I've also been thinking if the new Span<T> type would benefit the marshaling scenarios. But currently there is no plan to undertake neither of them.

Maybe if we get support for Vulkan 1.1.X, it's time to release v1.0.0 of VulkanCore. For now, I will move forward with delistings and releasing v0.1.0 sometime next week.