I’m considering using a single Github repository that will contain the code for more than one mix project, where each mix project is hosted on hex. I think it is a good idea for my usecase but wondered if there were any negatives I had not considered. Rather than discuss my usecase which is a project very much under development It might be easier to explain in the context of a more established project such as ex_aws.

Currently ex_aws has a single lib directory in which there is the code for iteration with many amazon services such as SNS S3 EC2. If following SemVer then a breaking change to any one of these pieces of functionality will require a major version change. However the majority of users are probably only using a fraction of the services available.

What would be the benefits/costs of changing to the following structure?

ex_aws (repo root)
-- ex_aws_s3 (individual mix project)
---- lib
------ s3
---- mix.exs
-- ex_aws_ec2 (another individual mix project)
---- lib
------ ec2
---- mix.exs

In this case a breaking change to ex_aws_ec2 could be released to hex without changing anything about ex_aws_s3.
In addition keeping them all together allows a single readme etc for documentation about the whole project.

For those whole are familiar I think I am looking for a way to implement something similar to the features feature available in the Rust ecosystem