Even if we don't think about 2.0, there are two main ways in which we can handle a stable branch in source control:
1) We can have a 1.0 branch and as new features and bug fixes are tried and tested in the dev area(s), then these patches are moved to the 1.0 branch as patch sets via some QA process. This will give us much better control and stability of our released versions, but it needs effort to control the patches moving into the 1.0 branch. If we look at the Linux kernel development style, they are very much in this style with patches coming from multiple development areas and being QA's into the main kernal branches. 2.0 development would fit nicely in this as it would just be another source of patches to be QA'd into branches. 2) We can continue development on a trunk and then every time we want to make a release we copy the trunk to a branch and have a few weeks stabalizing it and then release it. This is simpler for the developers, but the stability of final releases may suffer as stuff that your really didn't want will make it's way into releases. This means that the trunk can never be more than a few weeks away from a release. It also means that 2.0 cannot be developed in trunk as we can't just copy the whole blob. It also means that having multiple dev areas is difficult as there is no single source to copy a branch from and no culture of merging. We must decide which of these models we want to go with - regardless of 2.0 development. I think that geronimo is of a size and complexity that we should consider the overheads of approach 1). Formal compliance issues also push us towards good QA of all patches to stable releases. But to do so, we need to develop a culture flowing patch sets through a QA process. We will need multiple people responsible for controlling patches into specific subsystems and giving assurances to the main build manager that they have QA's the patches. These will be tough thankless jobs - maybe we should see if Linus wants a change from all that C hacking? cheers
