Could you please publish a new release?

[rugk]

Could you please publish a new release?

This would really help as issues like #504 with podman 4 are solved now and only a release is needed to publish them for all people.

[muayyad-alsadi]

the current devel branch introduces the following "different" experience

1. puts containers in a single pod
2. have custom systemd unit to start and stop the entire stack

I want to include the following in the final release

1. get the dependency PR merged
2. get the systemd right, and make sure it can be global or user
3. get the exit codes right

[rugk]

Hmm? All versions before v1.0.3 (or v1.0.0 in general?) had the same "different" experience AFAIK, as #504 shows, i.e. they used a single pod (you could just not disable that then) and (thus?) had one systemd unit to start and stop the pod (i.e. whole stack), if I understand that correctly.

So v1 was more of a breaking change than what you currently have in devel, but I have not tested the devel version and thus this is only my judgement from what I've read and tried with v1.

Anyway, sure, let's rather get stuff being done properly than rushing to put out an update. I am just asking, because, as I said, I have a breaking change that is already fixed in devel (said #504) and I very much would like to use it.
But again, sure, take what it needs, it does not help if something else breaks then…

[badnetmask]

Sorry if it sounds like I'm stealing this issue, I just don't see value in duplicating my request.

I also would like to see a new release published, because I have been using the RPM version packaged on Fedora 36, which is based on 1.0.3, but that release is missing #394 (merged after the release), which is required to make VS Code understand it can use podman-compose, instead of docker-compose.

For anyone who might need to get here via Google: when you try to run VS Code with a docker-compose file, you get "Docker Compose is required" error, because it's missing the option added by #394.

[mohd-akram]

@muayyad-alsadi Those sound like breaking changes. Would there be a major version bump? I think it would make sense to make that behavior optional via flags. After all, didn't v1 do the opposite, to match docker-compose's behavior and nothing more by default? Another breaking change would be painful, especially since EPEL 9 just added podman-compose and I presume there is a policy there of not bumping the major version during a RHEL cycle. I think those who rely on pod and systemd behavior are not using podman-compose in a Docker-compatible way in the first place, so they can and should explicitly specify additional behavior if they wish, or they can just use podman's own tools directly.

[muayyad-alsadi]

I'll not push a breaking change without a major jump in version. If I change put all containers in 1 pod, it will be compose 1.1.x not 1.0.x.

most likely I'll make the default in 1.0.x is not to put them in one container, so that it won't break current stable release that is 1.0.3

[rmeissn]

Would it be possible to simply add a CLI option to put containers in a pod or not? So you wouldn't need to break the 1.0.3 line and can still provide the option for people to use pods.

[muayyad-alsadi]

yes, indeed, in the current devel branch the option is --no-pod I need to make it something like --in-pod=yes|no (or --with-pod) and default to no for 1.0.x

[hunterloftis]

I would also ❤️ a new release, but for other folks running into the same error I've been debugging all day (for searchers: "Docker Compose required" in vscode), this sorted me out for now:

pip3 install git+https://github.com/containers/podman-compose.git@devel

[gitouche-sur-osm]

I would also heart a new release, but for other folks running into the same error I've been debugging all day (for searchers: "Docker Compose required" in vscode), this sorted me out for now:

pip3 install git+https://github.com/containers/podman-compose.git@devel

Thank you for this.
Digging further, Since devel might change, I'd rather specify an exact commit I can work with, for consistent bahaviour :

pip3 install git+https://github.com/containers/podman-compose.git@9d5b2559274819e3b47230da85d4d306807bb4bf

This is pretty much the same as having a release.

[zachsmith]

Also looking forward to the return of pod support as like @rugk, I rely on generated systemd units to start multi-container services.

[DevDorrejo]

pip3 install git+https://github.com/containers/podman-compose.git@9d5b2559274819e3b47230da85d4d306807bb4bf

this branch have an old error that affect 1.0.3 too, that it won't create network, at least the output is more explicit than 1.0.3. #552

[rugk]

Happy new year @muayyad-alsadi, BTW! 🎉
I'd be curious about the state of this issue, and if so, what is blocking a release of podman-compose?

[muayyad-alsadi]

I've just release 1.0.6

@rugk the latest stable at that time v1.0.3 did not create pods by default, I had to find some time to make 1.0.6 keep same default.

in current stable 1.0.6 --in-pod=0 to keep same old behavior, and new devel defaults to 1 which will be the new default for 1.1.x

[rugk]

Thanks a lot! Very happy about this! 😃 🎉