[Gtk-sharp-list] Please release gtk-sharp 2.99.4

Antonius Riha antoniusriha at gmail.com
Sun Feb 22 12:23:34 UTC 2015


Hi,
I agree with Tomi that it hurts development when PRs remain unattended.
Since the current plan (release 3.0 first, higher versions after that),
prevents contributions of higher version API, I think we should discuss
alternative development plans concerning the release of newer Gtk#
versions. I think, in addition to the current plan there are 2 alternatives:
 1. Use conditional compilation to build different API versions. Keep
all supported versions in the master branch. (The same as mono does with
various .NET profiles.)
 2. Create a branch for each Gtk# release and have unstable API in the
master branch.

Both approaches support simultaneous development of different Gtk#
versions. Both are feasible (though approach 1 would need PR #129 [1] to
be merged for working with bindinator's conditional code generation
feature).

What are your opinions on this? What are the pros and cons concerning
the alternative approaches?

- antonius

[1] https://github.com/mono/gtk-sharp/pull/129

On 2015-02-21 08:33, Tomi Valkeinen wrote:
> Hi,
> 
> It's been five months since the last commits to gtk-sharp git
> repository. Would someone please tag and release 2.99.4 so that we'd get
> the fixes into use in Linux distros?
> 
> What are the major missing things that need to be fixed before 3.0 can
> be released? While I'm personally fine with 2.99.x releases, I guess
> lots of people won't touch it until it's out of beta.
> 
> And while at the subject, I understand that the maintainers may not have
> time to spend on gtk-sharp, but if so, would it be better to just merge
> some of the merge requests like "Updated to Gtk 3.12" to keep the
> development going on, than wait until maybe some day 3.0 has been
> released before merging?
> 
>  Tomi
> 
> 
> 
> _______________________________________________
> Gtk-sharp-list maillist  -  Gtk-sharp-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
> 


More information about the Gtk-sharp-list mailing list