Re: Release Policy

[Adam Fedor]

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.
>
>
> 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?)
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.



> 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

Thanks. that makes sense now.