I have become more and more convinced that it would be beneficial to turn public-api and cargo-public-api into a mono-repo. Only on the repo level though. It still make a lot of sense for public-api and cargo-public-api to remain two distinct crates.
So all code would live in https://github.com/Enselic/cargo-public-api. And long-term possibly in https://github.com/cargo-public-api/cargo-public-api.
Pros
Easier development flow
There would only be a single project and git repo to manage in VS Code (or your IDE of choice).
And the default setup can be that cargo-public-api uses the local version of public-api. Right now that is an extra step, which makes development slightly less convenient than it could be.
Ability to re-use code for testing
The public-api repo has a very useful comprehensive_api test crate, for example. cargo-public-api would get access to that crate too.
Less duplicate efforts to make commits
There are many examples in the past where I essentially make the same commit to both projects, but separately. It would have been a lot more convenient to only have to make a single commit. TODO: Add examples
Easier to sync releases
Whenever we make a public-api release, we practically always also want to make a cargo-public-api release. Because we want to set the public-api dependency of cargo-public-api to the latest version, to ensure that users gets the latest and greatest functionality.
Having everything in the same repo makes it easier to sync releases.
It is however very possible that we in the future want to make only cargo-public-api releases, without bumping public-api. But a mono-repo does not prevent us from doing that.
Cons
I can't really think of any big cons. Losing some github stars, maybe? The project is still in the very early stages, so I think we can tolerate that :) Of course; the public-api repo will point towards the cargo-public-api repo.
Current status
This is still an idea. Before a final decision, we at the very least need a prototype commit to see how a mono-repo would look like. That is the next step for me.
@douweschulte Naturally, I would also love your feedback on this. (But as usual, there is no stress or urgency. I think this will be the last time I explicitly mention that :)
I have become more and more convinced that it would be beneficial to turn
public-apiandcargo-public-apiinto a mono-repo. Only on the repo level though. It still make a lot of sense forpublic-apiandcargo-public-apito remain two distinct crates.So all code would live in https://github.com/Enselic/cargo-public-api. And long-term possibly in https://github.com/cargo-public-api/cargo-public-api.
Pros
Easier development flow
There would only be a single project and git repo to manage in VS Code (or your IDE of choice).
And the default setup can be that
cargo-public-apiuses the local version ofpublic-api. Right now that is an extra step, which makes development slightly less convenient than it could be.Ability to re-use code for testing
The
public-apirepo has a very usefulcomprehensive_apitest crate, for example.cargo-public-apiwould get access to that crate too.Less duplicate efforts to make commits
There are many examples in the past where I essentially make the same commit to both projects, but separately. It would have been a lot more convenient to only have to make a single commit. TODO: Add examples
Easier to sync releases
Whenever we make a
public-apirelease, we practically always also want to make acargo-public-apirelease. Because we want to set thepublic-apidependency ofcargo-public-apito the latest version, to ensure that users gets the latest and greatest functionality.Having everything in the same repo makes it easier to sync releases.
It is however very possible that we in the future want to make only
cargo-public-apireleases, without bumpingpublic-api. But a mono-repo does not prevent us from doing that.Cons
I can't really think of any big cons. Losing some github stars, maybe? The project is still in the very early stages, so I think we can tolerate that :) Of course; the
public-apirepo will point towards thecargo-public-apirepo.Current status
This is still an idea. Before a final decision, we at the very least need a prototype commit to see how a mono-repo would look like. That is the next step for me.
@douweschulte Naturally, I would also love your feedback on this. (But as usual, there is no stress or urgency. I think this will be the last time I explicitly mention that :)