Re: Release Policy

[Richard Frith-Macdonald]

For clarity, a summary of what I think the unstable/stable  
distinction is/should be.


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 changes
9. 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 odd
6. Library .so version changes with minor version number and/or major  
version number
7. API may change
8. ABI may change
9. 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