Re: libgnomeoffice* status

[Rodrigo Moya <rodrigo gnome-db org>]

On Sun, 2003-09-21 at 06:47, Jody Goldberg wrote:
> On Fri, Sep 19, 2003 at 03:14:32PM +0000, Dave Malcolm wrote:
> > On Fri, 2003-09-19 at 10:44, Rodrigo Moya wrote:
> > 
> > [snip]
> > 
> > > > (iii)  Should I add the gnome-office module as an external dependency,
> > > > or should I create a cut-n-paste code subdirectory within my source
> > > > tree, and synchronise on a regular basis?
> > > >
> > > I guess the best thing is for all GO apps to depend on it externally.
> > 
> > Yes, but at the moment, are there tarballs I can tell my users to go and
> > download, with some kind of ABI guarantee?
> > 
> > If the lib is still changing a lot it seems wiser for now to do a
> > libegg-style approach and have a local copy inside my app's source tree,
> > and to declare the ABI as stable at some point when we make it external.
> > 
> > Currently I have no external dependencies apart from ones that come as
> > standard with Gnome 2.0, and I want to minimise the pain of adding new
> > ones.
> 
> Given that we have not yet begun to specify the interfaces never
> mind implement, test, or use them it would be premature to consider
> it.  My gut feeling an approach on the order of
> 
> 1) create a libgoffice tar ball release 0.0.x (to keep gnome ftp happy)
> 2) designate code in there as stable vs unstable api.
> 3) Have all of use link to that library but pick and choose the
>    interfaces depending on appetite for api instability.
> 
> Couple in some of egg's procedural requirements
>     - nothing goes in without a sponsor
>     - sponsor warrants to maintain the new blob and will remove it
>       if it does not come off the unstable list within 2 major
>       releases.  eg commit at 0.0.1 needs to be stable by 1.2, or it
>       gets removed.
>     - Nothing goes in if it duplicates or overlaps existing goffice
>       code.  Things need to be merged or refactored.
>
sounds good to me

cheers