[openi18n-im:01300] Re: [proposal] distribute parts of im-sdk separately

Hi Jens,

Great progress.

On Monday 14 March 2005 23:50, Jens Petersen wrote:
> So far what I have been doing is just to install "im-sdk/includes/"
> in a system directory and then have IM_INIT point IM_INCLUDEDIR to that
> directory, but I think it would be better if those private include files
> were moved to the appropriate project dir subdirs, which should then
> install (as semi-private if necessary).
>
> ("im-sdk/acfiles/" is okay of course since it can be used directly inplace
> for bootstrapping the tarballs of subdirs.  At least with a small hack.)
>
> I would like to suggest the following names for the separate tarballs:
>
> doc   ---> iiim-doc
> gnome-im-switcher ---> iiim-switcher-applet

Are we still calling it applet since we have migration to systray on the 
horizon.

> iiimecf   ---> iiim-emacs
> iiimgcf   ---> iiim-gtk
> iiimjcf   ---> iiim-java
> iiimqcf   ---> iiim-qt

As roger said, probably iiim-client-{}?

> iiimsf   ---> iiim-server
> iiimxcf/*  ---> iiim-xim ?

Yes a bit unsure on this one. Probably iiim-client-x or iiimf-client-xim?

> leif/<name>  ---> iiim-le-<name>
> lib/<name>  ---> iiim-lib-<name>
>
> So far I generated the following test tarballs which nearly all build.
>
> iiim-gtk-12.1.50.tar.gz
> iiim-leif-12.1.50.tar.gz  -- should be split up into LEs
> iiim-lib-client-12.1.50.tar.gz      \
> iiim-lib-eimil-12.1.2161.tar.gz      |
> iiim-lib-protocol-12.1.50.tar.gz     |  it would be nice to merge some of
> these iiim-lib-xiiimp-12.1.50.tar.gz      /
> iiim-server-12.1.50.tar.gz
> iiim-switcher-applet-12.1.50.tar.gz
>
> I have some patches to acfiles and the various configure.ac and
> Makefile.am files, needed to bootstrap them correctly so that they can
> build outside the im-sdk tree, which I would like to commit soon.
>
> One more issue is what to do with the version numbering of the individual
> packages?  In my tests I just set them all arbitrarily to 12.1.50 (ie they
> would all get released at version 12.2 say) but I'm not sure if that makes
> sense in all cases?  In the longer term I expect the version numbers of
> individual subpackages to start to diverge, but that does not matter: so
> the X.Y release of iiim would be defined as the set of packages with
> version X_i.Y_i. X_i.Y_i should only really get bumped up when there are
> changes to the package - there is no need or point to bump up the version
> just to keep all the version in sync: and some packages will surely need
> more frequent releases than others.

I think anything that has dependency will going to have same versioning 
system. It will help user/vendor identify the dependency and compatibility 
between them.

Having said that, I do believe language engines do not need to be included in 
that category. Hence it should able to have their own release & version.

I think we have to make a policy out of this once we get consenses to ensure 
consistent. 

Leon

>
> Does this all sound reasonable?  Please give comments and feedback.
>
> Cheers, Jens