105
edits
Changes
Jump to navigation
Jump to search
Line 111:
Line 111: − + + + Line 126:
Line 128: + + + + + + + + + + +
no edit summary
#* The [http://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html Migrating from GTK+ 2.x to GTK+ 3] should also be read.
#* The [http://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html Migrating from GTK+ 2.x to GTK+ 3] should also be read.
=== Version number considerations ===
== Other considerations ==
=== Version number ===
It goes without saying that such a migration would be the basis of a new major release. When this topic has been discussed before, people have toyed with the idea of calling the GTK3 version of Sugar "Sugar-1.0".
It goes without saying that such a migration would be the basis of a new major release. When this topic has been discussed before, people have toyed with the idea of calling the GTK3 version of Sugar "Sugar-1.0".
The migration of sugar-toolkit, sugar, datastore, etc, is likely to take more than 1 release cycle, but the above scheme can still apply. When each component is ported to GTK3, it would then pick up the 1.0 tag. For example, the first major release that includes any GTK3 may well include sugar-toolkit-1.0 (GTK3 ported) alongside sugar-datastore-0.96 (not yet ported).
The migration of sugar-toolkit, sugar, datastore, etc, is likely to take more than 1 release cycle, but the above scheme can still apply. When each component is ported to GTK3, it would then pick up the 1.0 tag. For example, the first major release that includes any GTK3 may well include sugar-toolkit-1.0 (GTK3 ported) alongside sugar-datastore-0.96 (not yet ported).
=== Python 3 ===
Is it worth throwing in a Python 3 migration into this project? I have researched the issue, and my opinion is: no.
* Python 3 brings no immediate obvious benefit, and does not fix any pressing problems. On the other hand, PyGI solves some clear breakage for us.
* Python 3 (or rather the code that supports it) is not mature. Many modules are still Python2-only.
* PyGI does support Python 3, but it was [http://mail.gnome.org/archives/python-hackers-list/2011-July/msg00000.html broken] when I tried it. It is not seeing much attention.
* Our neighbours within GNOME and other open source projects are only just starting to play with Python 3. There is not much similar experience we can build upon. There may be teething problems, such as modules that Sugar uses that haven't been ported, and bugs in existing ports due to lack of use (such as the fact that PyGI was broken for quite a while with nobody noticing) that hold us back. This is not so for the PyGI transition, where we can look at many PyGTK applications that have been ported and that are actively used.
* J5 (PyGI developer) suggested that we avoid combining the 2 migrations. It would add more change to an already disruptive project, and increases the risk. It would be better to limit the amount of change we introduce, so that risk is more manageable and to decrease the number of problems and challenges that we face.
* If the above situation does change, the Python 3 migration will be much easier than this one. Py3 migration does not require invasive code changes. It will be much easier to have Python 2 and 3 support maintained in parallel. The few existing projects that have done this are able to maintain Python2 and Python3 support in the same codebase, without too many if conditions. The "if we're already making so much change, why not avoid a future migration period by including Py3" argument is not very strong, because the Py3 migration will be much smoother and less complex.
== API changes ==
== API changes ==