Thanks for all the answers! I'll try to reply the main points.
On 27.01.2011 16:40, ext Didier 'OdyX' Raboud wrote:
With my Debian Developer and PPA maintainer hats on, I would really appreciate if the developement was to happen on two tracks; the short-term (unstable) track and the long-term (stable) track. If you could constrain yourselves to a "stable" branch on top of 1.0.0 (100% ABI backwards stability, bugfixes only, etc.), that would be just great (and I think for everybody out there), as it makes releases to distributions just easier. This branch could be updated trough "point releases", adding some functionality; what matters most for me is the ABI stability.
I agree that some kind of branching of the development is a necessity to cater both for the project "customers" (Python developers on different platforms) and platform packagers (such as yourself). The complication here is that I actually see three levels of progress here (coinciding with the x.y.z version numbering scheme).
- x.y.z (patch) updates would be bugfixes and trivial improvements which never cause an ABI break (and we need better tools to ensure this). These must happen relatively frequently to ensure that bugfixes can be provided in a timespan relevant to PySide users
- x.y.0 (minor) updates for bigger improvements such as support for new Qt versions, more substantial internal refactoring, or new Python versions. These would be guaranteed not to break the Python developer API but may break the internal ABI if that can't be avoided.
- x.0.0 (major) updates for major rework which provides potentially disruptive changes for the Python developer API (use of exceptions, properties, or any other yet-unformulated ideas).
I'd see that the z releases need to happen frequently (such as the proposed one-month cadence) to ensure bugfixes are provided on a timely basis.
Meanwhile, development for the next y (minor) version may need to be branched so that more substantial improvements can be developed simultaneously. The minor version releases could maybe happen something like not more often than every three months, but probably only when required, as opposed to a fixed cadence. However, after making the new minor release, I don't see that supporting the previous minor branch after a new release would be feasible, however (and there would be no benefit to the "customer" for doing that).
Major number releases would be issues happening very rarely: for example, I don't see any Nokia-sponsored work headed towards this would even start within the next 6 months. Such releases need to be planned on a case-by-case basis, and if there's no Python API compatibility between the major versions, the previous version would probably need to supported for quite some time -- but this is all speculation at this point.
Ah, and I think daily builds that would track ABI changes closely would be very important from the 1.0.0 release on (in particular for the "stable" branch). I am considering setting up some daily builds on Launchpad, but haven't yet succeeded in doing so (git import in bazaar is not complete enough to track various branches).
True, daily builds are essential. I've added an item for that in our internal backlog to be done right after the 1.0 release.
Cheers, ma. _______________________________________________ PySide mailing list PySide@lists.openbossa.org http://lists.openbossa.org/listinfo/pyside
