ABI changes become a bigger issue if we expect head to be functional, usable and stable because people will use it more. Indeed that's the point - make sure it is well exercised. That means we have to exercise significantly more care with regard to public ABI changes. There's lots of ways we can approach this, but we do have to be more thoughtful about it and reduce the gratuitous ABI churn.
Changing our development workflow goes a long way towards helping us get back towards having a vibrant 'head' development process and frees us from many of the self imposed burdens.
What is "stable" anyway?
How does one enforce a rule that 'head shall be functionally stable'?
Set up some ground rules, for example:
- If a commit breaks the tree, it is OK for the big-stick wielder to back out if it isn't promptly fixed.
- If a commit is big enough that it is inconvenient for the committer to have backed out, then do it in a feature branch first.
- If the tree gets non-trivially destabilized (where it can't be fixed easily/quickly with a backout), the big-stick wielder can call a freeze before things get out of hand.
There's several options:
- Cat herder keeps a public document describing feature changes that have landed, what's in the pipeline, and what we'd like to have finished before we bump revs.
- Or just stick with a time based cycle with some flexibility.
- Or a combination.. a wish-list document with a time limit.. ie: get these features done, or we hit 12 months, whatever comes first.
Release group mechanics?
We've released with a conventional svn/cvs style workflow in the past. Files have discrete revs. Something like Git Doesn't Work That Way. At all.
My inclination would be to live export our dvcs repo head to svn. Or, depending on the release group's goals, perhaps even just do a discrete import into their own repo.
dvcs hash revisions are useless for versioning unless the end users are also running the exact same dvcs. Security patches are release group repo centric. Planning how to do this in advance is critical.