docker-compose-rule
docker-compose-rule copied to clipboard
palantir
Release 1.0.0
docker-compose-rule is a fairly well established project - time to cut a 1.0.0 release and get the benefits of semver?
I believe the logic here is that we're still pretty aggressively changing the API (I know I broke it last release), and we'd want to do a through review before a 1.0.0 release. @joelea ?
To do a 1.0 and commit to semver, we'll need to define our API somehow. Obviously the top level DockerComposeRule class is in, but do we include all the other little ones? (HealthChecks.toHaveAllPortsOpen etc etc? Are we stuck with the ClusterWait name??)
@hpryce for opinions
I think we should 1.0. Worst case scenario is we have to do a 2.0 to do a breaking change.
My feeling is that we've not changed anything massive recently apart from the healthcheck stuff from @chrisalice, and I would've happily done a 2.0 to make that work properly.
As is always worth repeating, declaring a 1.0 version does not stop us doing anything, it just means we have to clearly indicate when we do certain things.
I would suggest we do the following and then ship 1.0:
- Remove the aggressive shutdown strategies as they don't make much sense any more
- Remove the is port open check that is basically a no-op
- Fix the issues with container restarting (logs, port caching etc)
The first two gets rid of things that people should not use. The last is something that I think people expect to work but I think might need some invasive changes that we should just do and get out the way.
Is a 1.0.0 release still in the works? I notice that no real development has been done since May.
Do you need help to cut a 1.0 release? We are not very keen on going outside Maven Central :-/
We are in a slight holding pattern as we determine the overall direction we want to take this project (as mentioned in https://github.com/palantir/docker-compose-rule/issues/181), but currently 1.0.0 is not in the works.
