|
From: | Adam Fedor |
Subject: | Re: Release Policy |
Date: | Thu, 8 Nov 2007 10:41:09 -0700 |
On Nov 8, 2007, at 12:28 AM, Richard Frith-Macdonald wrote:
For clarity, a summary of what I think the unstable/stable distinction is/should be.I think automating would be tricky - we probably want a human in there somewhere. But I can just put a reminder on my calendar, perhaps once a month, and make a release if needed then.Stable branch 1. Source of stable releases 2. Major version number never changes 3. Minor version number never changes 4. Subminor version number increments with each release 5. The minor version number is even 6. Library .so version never changes 7. API never changes 8. ABI never changes9. Each release implements internal bugfixes and/or non-functional updates (comments, improved documentation etc), 10. New releases should be within a few weeks of any bugfix (more often than we are doing so far ... can we automate this more somehow?) 11. New branches should be rare (when the latest unstable release has a new minor version number, or perhaps even less often?)
Trunk 1. Source of unstable releases 2. Major version number changes very rarely (for policy reasons)3. Minor version number changes rarely (when API BACKWARD compatibility is broken)4. Subminor version number increments with each release 5. The minor version number is odd6. Library .so version changes with minor version number and/or major version number7. API may change 8. ABI may change9. Releases may add, change, and remove API, but if API is changed/ removed (breaking compatibility) the minor version number must be bumped. 10. New releases are done whenever we feel there is enough change to merit it.11. New branches ... doesn't apply: there is only one trunk
Thanks. that makes sense now.
[Prev in Thread] | Current Thread | [Next in Thread] |