What about publish a beta version?

[tumashu]

May be we should publish a beta version and add it to melpa, In my opinion, we need more tester....

[girzel]

Probably true! I kept thinking that I would finish Vcard import/export before I put it on elpa, but maybe that's not necessary. Plus I got distracted by some work on Gnus... I would like to get the manual finished and formatted correctly in Info format, but then I'll add it to the repos.

[tumashu]

good news

[girzel]

I'm going to put this on ELPA soon. What do you think about separating the country libraries into separate packages? I imagine many people will only want to load the packages for the countries they're interested in. This would also reduce dependencies.

[tumashu]

In my opinion, all ebdb extensions which depend non-elpa package should not be included into elpa, maybe melpa is a good place for these extension.

maybe we should split ebdb to:

1. ebdb, in elpa. this is the core and basic of ebdb, which not depend and non-emacs and non-elpa package.
2. ebdb-i18n-"COUNTRY", maybe in melpa.
3. ebdb-ext, ebdb-swiper, ebdb-company, ebdb-helm, should in this package, which will be in melpa

[girzel]

It doesn't really matter whether a package is in elpa or melpa -- it's okay for elpa packages to depend on melpa packages. My only concern is, when users install EBDB, they shouldn't have to install a bunch of packages they will never use.

I like the idea of keeping all the ebdb-i18n-COUNTRY packages separate, that makes it a little more flexible. People can write and install whatever packages they like.

And yes, ebdb-company, ebdb-helm and ebdb-ivy would also be separate packages.

[girzel]

See the discussion on emacs.devel...

[tumashu]

A way is: we just publish a ebdb package, when ebdb stable and someone want to split a country package to maintain, we just split it.

[girzel]

Everything's basically in place...

[tumashu]

good job!!!