2008/7/11 David Abrahams <dave@boostpro.com>:
Yes, that is "standard practice." But standard practice for projects that care about stability is also that failures are not allowed to persist on the trunk.
This isn't necessarily the case; take the linux kernel for example which does care about stability, but the workflow they currently use ensures stability when it comes to release time, but in between during the 'merge window' instability is allowed. Speaking only for myself here, it seems like we can't get people to
operate that way; a really stable trunk, and development on branches just don't seem to be in our culture as a group. That's why I think we're maintaining a separate stable release branch.
I think that the reason development on branches isn't in the groups culture is because boost is actually a number of projects all under one umbrella title 'boost'. This means that there is little code contention because there is a high degree of code ownership; I get the impression that people generally don't hack on others code that much, apart from the odd bug fix. The other reason branches tend not to get used is that you don't get testing on other platforms. I am frankly not sure why Beman is inspecting the differences; it was my
presumption that we could do development in trunk without worrying about it, because the release branch is explicitly separated.
Indeed, I understand that he is making sure that developers have merged changes they intended to merge; as I know a number of them missed the official merge cutoff date, but again learning from the kernel release process, the equivalent 'merge window' caught out some developers initially but they were strict about it; I think that boost should take a similar stance since the developers learnt that they had to get their changes in during the window or wait for the next release, and once the momentum of releases picked up this was less of an issue. It also has helped with maintaining stability; since developers will tend to concentrate on working towards a particular release; if you know your changes are going to take slightly longer to develop then you target the next release, and by using DVCS this is easily done and doesn't ever create any confusion as the developer maintains his/her branch until its ready for integration upon which point a integration request is made and either further, wider testing occurs or it gets merged into the next release. James