On Mon, 2009-06-15 at 20:16 -0700, Todd Hodgen wrote: > It appears that all issues in 4.01 are now cleared up when I look at > the Projects folder. Will there be a 4.01 release, or will there > instead be a 4.02 release?
Yes - the 4.0.1 release will be copied out to the server shortly. The delay is just because we're setting up a new server for distributing binaries (we were getting hammered by bandwidth charges on the one they are on now, so we're moving them to a cheaper place - redirects will be in place so no URLs need change yet). We have created a version in the tracker for 4.0.2, but it's mostly a placeholder for things to be included if possible if&when we decide we need a release to fix some big bug - it may or may not ever actually happen. > And to clarify, are all of the fixes in 4.01 included in 4.1? Yes (or will be). > For a non-customer system, that will be used in office, what would you > recommend – 4.1 to provide testing for the developers, or 4.0X for > testing of the release versions? > I understand there are lots of answers here, my question is focused > more on what helps developers ensure features work, while at the same > time providing a somewhat stable platform to work from? 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. Historically, the second biggest source of instability has been database/upgrade incompatibilities*. Upgrading between development builds may be a rocky thing. 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/
