kocolosk commented on pull request #90: URL: https://github.com/apache/couchdb-pkg/pull/90#issuecomment-1031890385
Hi @nickva, yes, I hacked in metadata updates at d59bd6cca5dcddb2959b9539a9ae2af4fde3aba5, I only meant that we don't allow to drive the package versioning via environment variables currently. Convention seems to be that Debian packages can have an optional version 0, while RPMs start at release 1, so the packages I have ready to publish are e.g. > couchdb_3.2.1-1~bullseye_amd64.deb and > couchdb-3.2.1-2.el7.x86_64.rpm and > couchdb_3.2.1-1~bionic_amd64.deb That last one doesn't seem to quite follow the Ubuntu scheme exactly but maybe that's OK. Yes, I agree with the notion of being able to publish multiple package versions for a given CouchDB release, e.g. with updated Erlang builds. We haven't relied on this much to date. I'm not as familiar with specific guidance on the Docker side. It's complicated by the fact that a CI pipeline rebuilding images on a regular basis e.g. to pick up security updates in the underlying OS could have significantly more frequent updates. A 1:1 mapping between the container image tag and the CouchDB package could make sense, although you'd run into a little bit of friction because I'd expect you also want to tag an updated 3.2.1-1 package with the 3.2.1 tag, since unlike apt and yum Docker won't automatically pull the 3.2.1-1 image for you when you ask for 3.2.1. > Just to clarify, that would be 3.2.1 branch off of the 3.2.1 tag not off of the current 3.x? Something like: Yes, exactly. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
