Scott Lawrence wrote: [...]
> We are going to try to improve the stability of the mainline (4.1.x) > builds so that they are more usable during development. Ideally, they > will be usable right along, but they will always be significantly higher > risk than the 4.0.x 'stable' builds. > > To this end, significantly more feature work is going to be done on > branches during this release cycle, merging back to main (and thus into > the 4.1.x builds) only when the feature is believed to be reasonably > stable. I like it: while I am a big fan of "merge early and merge often" strategy we should refrain from submitting the code that does not work into mainline (what I mean by that: we are only humans, mistakes will happen - but there is no need to treat the mainline as a backup storage for unfinished code). Even smaller features can be developed and clean on a branch and git light branches are really good for that. And even if you are developing with someone you can use git hub to share you branches and get the feature in shape before getting it back to mainline. Of course svn branches are perfectly valid solution if you happen to be a fan of doing things the hard way ;-) > > Historically, the second biggest source of instability has been > database/upgrade incompatibilities*. Upgrading between development > builds may be a rocky thing. > And it's probably going to stay that way: if you are on mainline you need to be ready to drop DB if something goes wrong. However - there is one improvement in 4.0 that'll make life a bit easier for our invaluable mainline users (thanks again for all the issues you found and reported!). As long as you have current backup from the version before the upgrade you now can restore it after upgrade... That gives us the opportunity to fix any upgrade issues and get you going again without the need to start from scratch. Another source of instability during 4.0 cycle were start-up problems. I would think that we have to have an automatic test that proves that freshly installed system actually starts. sipXconfig has such tests (unfortunately our server just died: I need to spend some time rebuilding it). But sipXconfig starting is not the same as entire sipXecs starting... And finally 4.2 needs to be much smaller release than 4.0 was so that people do not wait for a stable version that long. I'd like us to agree that whatever we have ready by the end of summer will become 4.2 release. > I'd like to hear more discussion from both users and developers on this > - can we keep mainline stable enough for the braver and more skilled of > our users to actually run it all the time? I'm not suggesting that > every single build need be usable, but what update frequency do people > think we could achieve? > > This topic is really better suited to sipx-dev, so I've directed replies > there... > > * The biggest source of instability is, of course, unanticipated > protocol incompatibilities and other sorts of bugs. Hopefully, these > will be caught more often in the branch testing. > > _______________________________________________ > sipx-dev mailing list [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev > sipXecs IP PBX -- http://www.sipfoundry.org/ _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
