Re: [RFC] Proposal for GtkSourceView 3.24, 3.50 and 3.90
On Wed, Nov 02, 2016 at 04:55:40PM -0700, Matthew Brush wrote: > It's nice to support a range of versions so that people with older distros > can use a new version, and people with newer distros can use new features, > etc. Generally it's easy enough, like say supporting GTK 2 and 3, where most > of the stuff is the same or still works. This is also useful for supporting > other platforms like Windows where you're stuck with whatever bundled > versions you can find or whatever's packaged in msys. Ok, I have a different opinion. I don't like writing conditional code depending on a certain version of a library. It makes the code harder to read (and thus can contain more bugs) and harder to test. But I understand that it can be useful to use a new version of an app on an old distro. In the future container systems like Flatpak will be much more widespread I think, so it'll make app development easier, you can target only one version of GTK+ and be able to install the app on old distros or newer distros. > I will probably go this route if the need arises. Are you planning to use a > script to automate the renaming of symbols? If so, that might be useful for > generating such a header. I will use scripts from: https://github.com/swilmet/gnome-c-utils I don't think those scripts can be useful for generating a compatibility header. I will just do a substitution GtkSource -> Gsv, not each symbol separately. -- Sébastien ___ gnome-devtools mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-devtools
Re: [RFC] Proposal for GtkSourceView 3.24, 3.50 and 3.90
On 2016-11-02 04:53 AM, Sébastien Wilmet wrote: On Tue, Nov 01, 2016 at 07:57:47PM -0700, Matthew Brush wrote: Do you have any recommendations for applications wanting to support a range of GSV versions from before and after the rename? [...] If you want to write new code in 2016 and still want to run that code on an LTS distro from 2014, then use only APIs that are available in the GTK+ and GtkSourceView versions from 2014. GtkSourceView has kept a good backward-compatibility. GTK+ less so (for the CSS etc). So while it can make sense to write conditional code depending on the GTK+ version to make the app work with different versions of GTK+, it doesn't make sense for GtkSourceView, in my opinion. It's nice to support a range of versions so that people with older distros can use a new version, and people with newer distros can use new features, etc. Generally it's easy enough, like say supporting GTK 2 and 3, where most of the stuff is the same or still works. This is also useful for supporting other platforms like Windows where you're stuck with whatever bundled versions you can find or whatever's packaged in msys. Renaming every symbol makes things a bit more challenging though, not that I think it's a bad idea. [...] I guess making a header with a bunch of #defines mapping to the old names would work, but perhaps there's something less tedious I missed, or some compatibility path planned? A header with a bunch of #defines could be written, if it is really useful for some applications, why not. But I'm not going to write it :-) I don't need it, and I don't see why it would be useful. But contribution welcome. I will probably go this route if the need arises. Are you planning to use a script to automate the renaming of symbols? If so, that might be useful for generating such a header. Thanks for the response. Regards, Matthew Brush ___ gnome-devtools mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-devtools
Re: [RFC] Proposal for GtkSourceView 3.24, 3.50 and 3.90
On Tue, Nov 01, 2016 at 07:57:47PM -0700, Matthew Brush wrote: > Do you have any recommendations for applications wanting to support a range > of GSV versions from before and after the rename? What GNOME applications do is to follow the GTK+ release schedule (or, more correctly, GTK+ 3 has followed the GNOME release schedule). With a new minor release every 6 months. If you want to install a GNOME application on an old LTS distro, you install the version of the application corresponding to the GTK+ version shipped by the distro. Say, gedit 3.14 for GTK+ 3.14. If you want to write new code in 2016 and still want to run that code on an LTS distro from 2014, then use only APIs that are available in the GTK+ and GtkSourceView versions from 2014. GtkSourceView has kept a good backward-compatibility. GTK+ less so (for the CSS etc). So while it can make sense to write conditional code depending on the GTK+ version to make the app work with different versions of GTK+, it doesn't make sense for GtkSourceView, in my opinion. Now with the long term stability promise of GTK+, you can just target GTK+ 3.22. In the future the only GTK+ 3 version available in LTS distros will be the 3.22. So it'll make things simpler. Ditto when 4.0, 5.0 etc will be released. Another thing that will make things simpler is container systems like Flatpak. > I guess making a header > with a bunch of #defines mapping to the old names would work, but perhaps > there's something less tedious I missed, or some compatibility path planned? A header with a bunch of #defines could be written, if it is really useful for some applications, why not. But I'm not going to write it :-) I don't need it, and I don't see why it would be useful. But contribution welcome. -- Sébastien ___ gnome-devtools mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-devtools
Re: [RFC] Proposal for GtkSourceView 3.24, 3.50 and 3.90
On 2016-11-01 04:43 AM, Sébastien Wilmet wrote: On Fri, Oct 21, 2016 at 01:55:58PM +0200, Sébastien Wilmet wrote: I've updated the wiki page with that proposal (Proposal 2) and added a third proposal, a mix of Proposal 1 and 2: https://wiki.gnome.org/Projects/GtkSourceView/TransitionToGtkSourceView4 And I've now added a fourth proposal, in my opinion more logical: just bump the major version since there is an API break (and a major one). GtkSourceView based on GTK+ 4.0 (stable) will happen only in 2 or 3 years. Changing the GtkSourceView namespace will happen this development cycle. So it would be great if existing applications are able to use the new namespace while still using GTK+ 3. It would be one less thing to care about when porting an application to GTK+ 4.0. Also, between March 2017 and GTK+ 4.0, new apps or new libraries can be developed, depending on GtkSourceView. So when writing that new code, it would be better to use the new namespace. Hi, Do you have any recommendations for applications wanting to support a range of GSV versions from before and after the rename? I guess making a header with a bunch of #defines mapping to the old names would work, but perhaps there's something less tedious I missed, or some compatibility path planned? Regards, Matthew Brush ___ gnome-devtools mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-devtools
Re: [RFC] Proposal for GtkSourceView 3.24, 3.50 and 3.90
On Fri, Oct 21, 2016 at 01:55:58PM +0200, Sébastien Wilmet wrote: > I've updated the wiki page with that proposal (Proposal 2) and added a > third proposal, a mix of Proposal 1 and 2: > https://wiki.gnome.org/Projects/GtkSourceView/TransitionToGtkSourceView4 And I've now added a fourth proposal, in my opinion more logical: just bump the major version since there is an API break (and a major one). GtkSourceView based on GTK+ 4.0 (stable) will happen only in 2 or 3 years. Changing the GtkSourceView namespace will happen this development cycle. So it would be great if existing applications are able to use the new namespace while still using GTK+ 3. It would be one less thing to care about when porting an application to GTK+ 4.0. Also, between March 2017 and GTK+ 4.0, new apps or new libraries can be developed, depending on GtkSourceView. So when writing that new code, it would be better to use the new namespace. Another thing, for us, backporting commits would be easier with the same namespace. -- Sébastien ___ gnome-devtools mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-devtools
Re: [RFC] Proposal for GtkSourceView 3.24, 3.50 and 3.90
On Thu, Oct 20, 2016 at 01:39:11PM +0200, Sébastien Wilmet wrote: > On Thu, Oct 20, 2016 at 12:19:40PM +0200, Sébastien Wilmet wrote: > > Since it will be possible to break the GtkSourceView API (since it'll be > > a new major version, fully parallel-installable), there is one big API > > break planned: renaming the namespace from GtkSource to Gsv, see: > > https://bugzilla.gnome.org/show_bug.cgi?id=755752 > > I've sent this mail on gtk-devel-list, to ask the opinions of GTK+ > developers, since they are concerned: > https://mail.gnome.org/archives/gtk-devel-list/2016-October/msg00010.html I've also asked on the #gtk+ IRC channel, and everybody who responded agreed that it was a good thing to rename the namespace to Gsv. -- Sébastien ___ gnome-devtools mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-devtools
Re: [RFC] Proposal for GtkSourceView 3.24, 3.50 and 3.90
On Thu, Oct 20, 2016 at 12:40:45PM +0200, Paolo Borelli wrote: > If needed we can make the first gtk 3.90.0 release just be the > namespace change without bumping gtk and bump in gtk in 3.90.1 so that > people doing the porting have a stepping stone. The ABI break between > 3.90.0 and 3.90.1 would not be a problem since 3.90 series is not abi > stable anyway. GTK+ 3.90.0 will be released in March 2017. So it's more logical to release GSV 3.90.0 at the same time, depending on GTK+ 3.90. The next development versions of GTK+ will be 3.89.x. So what you propose above can be done with GtkSourceView 3.89.x releases (not 3.90.x, but that's a detail). I agree that it's another good proposal. I've updated the wiki page with that proposal (Proposal 2) and added a third proposal, a mix of Proposal 1 and 2: https://wiki.gnome.org/Projects/GtkSourceView/TransitionToGtkSourceView4 BTW I think GTK+ should do something similar to Proposal 2, to port some code incrementally to GTK+ 4 (not all API breaks at the same time, especially for those who will port an app from GTK+ 3 to GTK+ 4.0 at once, two years worth of API breaks :/ ). -- Sébastien ___ gnome-devtools mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-devtools
Re: [RFC] Proposal for GtkSourceView 3.24, 3.50 and 3.90
On Thu, Oct 20, 2016 at 12:40:45PM +0200, Paolo Borelli wrote: > honestly the plan sounds too complicated to me. It is confusing to > me, and I am watching the development fairly closely, I suspect that for > other downstream users of the library it would be too much churn. > > I propose to simply: > > 1) keep the stable gtk3 release in sync with the gnome versioning (3.22) > with deprecations etc. The two minor API additions seems very minor > features and I think they can wait for the next devel cycle, so in a few > months we will release 3.24 with those additions as we usually do > 2) Release 3.90 that uses gtk 3.90 and does the namespace change. The > namespace change is pretty mechanical so it can be easily done at the same > time of adopting gtk4 and having a stable gtk3 version with just the > namespace change is overkill and the weird version number will confuse > people. If needed we can make the first gtk 3.90.0 release just be the > namespace change without bumping gtk and bump in gtk in 3.90.1 so that > people doing the porting have a stepping stone. The ABI break between > 3.90.0 and 3.90.1 would not be a problem since 3.90 series is not abi > stable anyway. Some rationales for doing a 3.50 version: Although the namespace change is mechanical, for some apps it results to a huge commit. So it is better to be able to compile the code, run the unit tests, etc. Because the port to GTK+ 4, just to be able to compile the code again, it can also result to a huge commit (or it's probably better to create a branch, even if it doesn't compile at each commit). It is important to be able to compile and test the code as often as possible, and doing small incremental steps. Also, for the namespace change, a script will be provided for C code, but not for other languages. In Python or JS, there is no compilation so it is even harder to make sure that nothing broke. Another thing, for developers wanting to write a new app in GTK+ 3 (GTK+ 4 will be stable only in two years or more), it would be better to directly use the Gsv namespace, it would be stupid to write new code when GtkSourceView has already changed its namespace on the master branch. -> And that's a rationale for doing an actual release/tarball of 3.50, not just keeping it in Git. And anyway, developers can skip the 3.50 version and use directly 3.90, if they are confident enough. But personally, for the code I develop/maintain that depends on GtkSourceView (Gtef, LaTeXila and gCSVedit), I would prefer having the 3.50 intermediary step. -- Sébastien ___ gnome-devtools mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-devtools
Re: [RFC] Proposal for GtkSourceView 3.24, 3.50 and 3.90
On Thu, Oct 20, 2016 at 12:19:40PM +0200, Sébastien Wilmet wrote: > Since it will be possible to break the GtkSourceView API (since it'll be > a new major version, fully parallel-installable), there is one big API > break planned: renaming the namespace from GtkSource to Gsv, see: > https://bugzilla.gnome.org/show_bug.cgi?id=755752 I've sent this mail on gtk-devel-list, to ask the opinions of GTK+ developers, since they are concerned: https://mail.gnome.org/archives/gtk-devel-list/2016-October/msg00010.html If we decide to keep the GtkSource namespace, then the 3.50 version is not needed. -- Sébastien ___ gnome-devtools mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-devtools
Re: [RFC] Proposal for GtkSourceView 3.24, 3.50 and 3.90
Hi Sébastien, honestly the plan sounds too complicated to me. It is confusing to me, and I am watching the development fairly closely, I suspect that for other downstream users of the library it would be too much churn. I propose to simply: 1) keep the stable gtk3 release in sync with the gnome versioning (3.22) with deprecations etc. The two minor API additions seems very minor features and I think they can wait for the next devel cycle, so in a few months we will release 3.24 with those additions as we usually do 2) Release 3.90 that uses gtk 3.90 and does the namespace change. The namespace change is pretty mechanical so it can be easily done at the same time of adopting gtk4 and having a stable gtk3 version with just the namespace change is overkill and the weird version number will confuse people. If needed we can make the first gtk 3.90.0 release just be the namespace change without bumping gtk and bump in gtk in 3.90.1 so that people doing the porting have a stepping stone. The ABI break between 3.90.0 and 3.90.1 would not be a problem since 3.90 series is not abi stable anyway. Ciao, Paolo On Thu, Oct 20, 2016 at 12:19 PM, Sébastien Wilmet wrote: > Hi, > > GTK+ 3.90 is planned for March 2017: > https://blog.gtk.org/2016/09/01/versioning-and-long-term- > stability-promise-in-gtk/ > > If everything goes fine, GtkSourceView 3.90 is also planned for March > 2017, to follow the unstable version of GTK+. > > Since it will be possible to break the GtkSourceView API (since it'll be > a new major version, fully parallel-installable), there is one big API > break planned: renaming the namespace from GtkSource to Gsv, see: > https://bugzilla.gnome.org/show_bug.cgi?id=755752 > > Here is a proposal to be able to port an application (more) smoothly to > GTK+ 4 and GtkSourceView 4: > https://wiki.gnome.org/Projects/GtkSourceView/TransitionToGtkSourceView4 > > The plan is to release in a few weeks the 3.24 version. Then 3.50 when > it's done, and then port the GtkSourceView code to GTK+ 3.90. > > What do you think? Does it sound a good plan? > > If there are no major disagreements, I can ask the GNOME release team > what they think, and then send an e-mail to the distributor-list if we > have the green light. > > -- > Sébastien > ___ gnome-devtools mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-devtools
