Ed Leafe wrote: > On Jan 15, 2007, at 4:46 PM, Paul McNett wrote: > >>> OK, my misunderstanding. I thought that when we do a release, it >>> would take the trunk and call it 0.7.2, but you're saying that 0.7.x >>> is permanently forked from the trunk, right? >> Your above paragraph is true when we do major releases (0.6.x to 0.7, >> for example), but when we do minor releases (0.7.1 to 0.7.2) we >> maintain the bugfix-only policy and only backport the needed >> things, in >> order to keep it 'stable', which means that features and API don't >> change. > > So the only way to get any new code into general release is to wait > for a 0.x release?
That's how we've been doing it since I think 0.6. It forsees the day when we have lots of users running Dabo 1.2.1 (stable) and we are banging away on Dabo 1.3 (dev). We find bugs and release 1.2.2 stable, and the users upgrade to that. Eventually we decide that development on 1.3 has stabilized and it's time to start developing 1.4. We roll out a final 1.2.3, and then make 1.3 the stable version and make a big announcement. Most people wisely wait until 1.3.1 comes out though, for the unavoidable post-release bugfixes. > I guess that I thought that the purpose of stable was to have a > known release for which only bugfixes would be done. IOW, we release > 0.7. We then start working on new stuff, and along the way discover > some things that were wrong. We fix them in the new code, and > backport those fixes to the 0.7 stable code. Then, after a while, we > release 0.7.1, which becomes the new stable branch. And I've been making stable releases, that wrap up the bugfixes to a known stable release version. Otherwise, in order for someone to get the latest stable, they'd essentially have to use Subversion, or we'd put in a nightly build like we have for the dev branch but that doesn't give them an exact version number to know what they are running. > We then continue working, and then discover more such problems. We > fix those in the current dev code, and also in the 0.7.1 stable code. > Later, we release 0.7.2, and that becomes the new stable branch. I'm surprised you didn't realize what we've been doing, as this is the tenth dabo stable release we've made using this system (beginning with Dabo 0.6). > I thought that the only changes we did not build into releases were > things that would clearly break old code, such as the dependence on > SQLite that we added in 0.7. But we're not talking about that here; > in fact, the only things we've done is fix a lot of the older code to > make it better, not incompatible. I agree that the current dev trunk (0.8a) is superior to the current stable branch (0.7.2s), however there needs to be a trailing stable that people can rely on while the development happens in the highly-volatile trunk. That way, by the time of the next major release (0.8s), all the great new things we've done will have already survived weeks if not months of use and refinement. I don't believe we are acting differently than the average open source project here. FWIW what you describe is basically what we were doing up until 0.6, except we didn't have a stable branch at all. -- pkm ~ http://paulmcnett.com _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
