Stable API

[dxyinme]

是否需要将API稳定下来，开发一个稳定版本？
可以一起讨论下还有哪些欠缺的功能需要提供，以及对现有API的改进。

[libi]

API感觉还能继续优化一下,我觉得有2个点:

1. 已经把cron内置了,所以dcron的初始化函数可以和cron一样了.最终实现的效果就是之前使用cron的用户只需要替换包名就能无缝替换. 如果需要启用分布式,附加带driver的配置即可.
2. driver包独立:项目本身依赖的三方库其实并不多,主要是各个driver引入带来的间接引入.所以可以考虑将driver目录整合一下提取出接口,具体实现都使用独立包含go.mod的子目录(一个仓库下的多个go mod). 这样对于只使用主项目时的依赖会非常简洁.

[dxyinme]

关于driver包独立：
这两天尝试了一下发现想要独立出去略微有些困难，有一种方法是对于每一个driver新开一个repo，要在一个仓库下的话，可能就要用go work来共同管理了

[libi]

关于driver包独立： 这两天尝试了一下发现想要独立出去略微有些困难，有一种方法是对于每一个driver新开一个repo，要在一个仓库下的话，可能就要用go work来共同管理了

每个driver新开一个 repo 和 使用子目录新的go.mod实现基本是一样的， 如果子目录下有go.mod 这个子目录对于go就是一个独立的包名，不会受到主仓库的影响。

[dxyinme]

https://github.com/dxyinme/dcron/tree/dxyinme/move-driver-to-inner-mod/driver

正在做这部分的工作，具体进度可以在这个branch里面看到

• 抽取实现driver需要的公共方法作为一个新的go mod
• 独立出etcd driver
• 独立出redis driver
• 独立出redis zset driver
• 独立出integration test
• 独立出examples
• 增加拆分go mod之后的test coverage
• 让github actions可以测试到所有的mod

[dxyinme]

#103

[dxyinme]

由于github一个repo只能发布一个go mod的原因，所以创建了一个org用来放dcron的其他包 https://github.com/dcron-contrib

[little0919]

API感觉还能继续优化一下,我觉得有2个点:

1. 已经把cron内置了,所以dcron的初始化函数可以和cron一样了.最终实现的效果就是之前使用cron的用户只需要替换包名就能无缝替换. 如果需要启用分布式,附加带driver的配置即可.
2. driver包独立:项目本身依赖的三方库其实并不多,主要是各个driver引入带来的间接引入.所以可以考虑将driver目录整合一下提取出接口,具体实现都使用独立包含go.mod的子目录(一个仓库下的多个go mod). 这样对于只使用主项目时的依赖会非常简洁.

关于第一点，我看现在 dcron 包的 AddFunc() 方法比原来 cron 的多了一个 jobName 字段，导致不能直接换个包名就完成分布式的切换。
jobName 是用于唯一标识任务、以及用于计算任务的hash，是否能去掉 name 字段，直接用 cron 生成的 id 呢？

[dxyinme]

API感觉还能继续优化一下,我觉得有2个点:

1. 已经把cron内置了,所以dcron的初始化函数可以和cron一样了.最终实现的效果就是之前使用cron的用户只需要替换包名就能无缝替换. 如果需要启用分布式,附加带driver的配置即可.
2. driver包独立:项目本身依赖的三方库其实并不多,主要是各个driver引入带来的间接引入.所以可以考虑将driver目录整合一下提取出接口,具体实现都使用独立包含go.mod的子目录(一个仓库下的多个go mod). 这样对于只使用主项目时的依赖会非常简洁.

关于第一点，我看现在 dcron 包的 AddFunc() 方法比原来 cron 的多了一个 jobName 字段，导致不能直接换个包名就完成分布式的切换。 jobName 是用于唯一标识任务、以及用于计算任务的hash，是否能去掉 name 字段，直接用 cron 生成的 id 呢？

很好的建议，我正在考虑