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

[Bertrand Lorentz]

Hello,

Thanks for bringing up this topic.

I did the previous 2.99.x, but only because nobody else was doing it, and
someone was foolish enough to give me commit access on the GitHub repo.
I've always considered myself as the "de facto acting maintainer" of the
master branch, but not much else.

In the last 5 months, I haven't been able to do any open source stuff in
general, so nothing for Gtk# in particular. My day job has been using up
all my brain juice, and getting a new apartment has not helped either.
I'm sorry for not addressing the pending PRs.

I hope I'll be able to get back to contributing, but I can't make any
promises. I'm of course open to suggestions on how to make things better,
and also for people who want to take over maintainership.
I don't way to block cool stuff from happening.


Regarding the strategy for newer GTK+ API and Gtk# releases:
My idea was, once git master reached a certain level of maturity, to create
a 3.0 branch, which would be API-stable and bug fixes only.
Git master could then be updated to bind the GTK+ 3.12 or 3.14 APIs, which
would then itself be branched off when it's mature.
So that's approach 2 described by Antonius.

I know that Gtk# 2.12 and before uses something like approach 1. See for
example:
https://github.com/mono/gtk-sharp/blob/gtk-sharp-2-12-branch/bootstrap-2.12

This was removed in the early days of porting to GTK+ 3, see:
https://github.com/mono/gtk-sharp/commit/fe2d4c311

I don't know exactly what the pros and cons of that approach were, it was
before I was involved.
But I think nowadays with git it's much easier to maintain each API in it's
own branch, and merge what is needed from one to the other. Doing this with
SVN at the time would probably have been painful.

What do you think ? How far are we from being able to delare the Gtk# API
stable for 3.0 ?

Cheers,

--
Bertrand

On Sun, Feb 22, 2015 at 1:23 PM, Antonius Riha <antoniusriha at gmail.com>
wrote:

> 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
> >
> _______________________________________________
> Gtk-sharp-list maillist  -  Gtk-sharp-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/gtk-sharp-list/attachments/20150225/894915b6/attachment.html>