We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 3916 - proposal for bug-fix-only stable branches
Summary: proposal for bug-fix-only stable branches
Status: NEW
Alias: None
Product: SDL
Classification: Unclassified
Component: *don't know* (show other bugs)
Version: HG 2.0
Hardware: All All
: P3 enhancement
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-10-24 09:44 UTC by programmerjake
Modified: 2017-10-24 09:45 UTC (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description programmerjake 2017-10-24 09:44:40 UTC 
I think it would be useful to release bug-fix-only stable branches for one or more versions of SDL and/or related libraries because, currently, each new release adds (sometimes extensive) new features and inadvertantly adds more bugs.
This would also provide a mechanism to easily release critical security bug fixes without having to wait for the development branch to become stable enough to release.
I think this could be implemented by somehow providing a simple mechanism for bug-fix commits to be proposed for addition to the stable branches while allowing for possible changes required for back-porting the fix.

for versioning, I think we could use something like 2.0.6.1 or 2.0.6-1 as the version number for the first bug-fix release based on 2.0.6.

Alternatively we could the versioning system described in SDL_version.h and start incrementing the minor version for backwards compatible changes, instead of how the patch number has been incrementing even though there have been some non-trivial additions (new audio resampling system, vulkan support, etc.). Then, when a non-backwards-compatible change is made, we'd switch the version to 3.0 instead of 2.1. To facilitate this, what would have been named 2.0.8 will be called 2.1.0 or 2.1.1 instead. I think it would be better to leave the already released versions with their original version numbers to reduce confusion.