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.
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev