[Gtk-sharp-list] GtkSourceView 2 Bindings

Mike Kestner mkestner at ximian.com
Fri Aug 3 16:58:25 EDT 2007


Hi Michael.  

Thanks for looking into this.

On Thu, 2007-08-02 at 16:09 +0100, Michael Hutchinson wrote:

> As tempting as it is just to fork the binding into a new SVN module
> and call it gtksourceview2-sharp-2.0, this is probably too confusing.
> I think the best route is to branch the gtksourceview-sharp SVN module
> into a 1.x bugfix version, then re-version trunk to 0.20 (pc) and
> 2.0.0.0 (dll). The two versions' .pc files will be incompatible,
> though versioned to allow distinguishing them; this will affect
> developers, but the dlls will be parallel installable for end-user
> backwards compatibility.

Yeah, it's an ugly situation.  I think the best thing is to blow it up
and start over, sort of.  The .pc filename is a problem.  If you stick
with the same name, you can break existing released software builds.  I
don't think that's a good idea.  

Other than a recent packaging fix, the last change to the binding was
about two years ago, so I'd say branching is a good idea instead of
leaving a dead module in trunk.  The current release will most likely be
the final release of the 0.x series.

After the branch, I would svn mv trunk to gtksourceview2-sharp and
change the package name in the configure.in.  You could svn mkdir a
gtksourceview-sharp module and add an empty file named
now_located_at_branches_gtksourceview_sharp for the curious.  

Make the new .pc file gtksourceview2-sharp.pc without the -2.0.  The
assembly version looks right.  You might as well make the package
version 1.9.x leading up to a 2.0.0.  

The other alternative I see would be to leave the package named
gtksourceview-sharp, and just version the pc file -2.2.  We've had a
-2.0.pc file binding 1.x for the past few years, so it's not
unprecedented.  ;-)  The main problem I see with that is when
gtksourceview gets to 2.4, your .pc file is still going to be 2.2 to
maintain backward compat, assuming they can restrain themselves on the
compat front from here out.

That will be more confusing long-term than gtksourceview2-sharp.pc.  Any
confusion between gtksourceview-sharp-2.0.pc and gtksourceview2-sharp.pc
will be short-lived as version 1.x of the native library fades from the
landscape.  I tend to vote for short-term confusion over long.  The name
difference is also easily explained.  The gtksourceview2 refers to the
native lib.  The sharp-2.0 refers to the binding, ie second version of
the gtksourceview(1) binding.

-- 
Mike Kestner <mkestner at ximian.com>



More information about the Gtk-sharp-list mailing list