Latest git master is pushed to docker hub instead of stable release

[Derkades]

Since February 28th, our phpDoc builds are failing with this error message:

0.894 
0.898                                      
0.898   No arguments expected, got "run".  
0.898                                      
0.898 
0.898 project:run [-t|--target [TARGET]] [--cache-folder [CACHE-FOLDER]] [-f|--filename [FILENAME]] [-d|--directory [DIRECTORY]] [--encoding [ENCODING]] [--extensions [EXTENSIONS]] [-i|--ignore [IGNORE]] [--ignore-tags [IGNORE-TAGS]] [--hidden] [--ignore-symlinks|--no-ignore-symlinks] [-m|--markers [MARKERS]] [--title [TITLE]] [--force] [--validate] [--visibility [VISIBILITY]] [--defaultpackagename [DEFAULTPACKAGENAME]] [--sourcecode|--no-sourcecode] [--template [TEMPLATE]] [--examples-dir [EXAMPLES-DIR]] [-s|--setting [SETTING]] [--list-settings] [--parseprivate]
0.898 

There has not been any phpDoc release, so I wouldn't expect the command usage to have changed.

This is our Dockerfile (unmodified since September 2023):

FROM phpdoc/phpdoc:3.4 as doc_builder

COPY . /source

WORKDIR /source

RUN mkdir /target && \
    phpdoc run \
        -d 'core/classes' \
        -d 'modules/Core/classes' \
        -d 'modules/Discord Integration/classes' \
        -d 'modules/Cookie Consent/classes' \
        -d 'modules/Forum/classes' \
        -d 'modules/Members/classes' \
        -i vendor \
        -t /target

FROM nginxinc/nginx-unprivileged:stable

COPY --from=doc_builder /target /usr/share/nginx/html

Source: https://github.com/NamelessMC/Nameless/blob/34d17a0886416d08ba540a6b96a7ce8d2f362f14/Dockerfile.phpdoc

It seems that the Docker image was updated to a development version:

$ docker run -it --rm phpdoc/phpdoc:3.4 phpdoc --version
phpDocumentor v3.4.2-dev-master+66ae390

[jaapio]

Hi, sorry for the bad experience you have with our container. We had the intention to create a rolling release to make users benefit as soon as possible from all the changes we make. As you might notice we do not tag on a regular basis. Our team is too small to have a release schedule. We tried to solve it this way.

Maybe the unstable nightly tags will help you to stay fixed on a certain version. Or use the previous tagged version. Only the 3.4.* versions are not changing in this approach.

Please let me know what you think, I'm open for all feedback.

[Derkades]

Hi, thanks for your response. It is understandable that pushing an image for every commit is desirable when the release schedule is slow. However, I think most people would expect images to at least somewhat follow semantic versioning. So pinning to 3.4 would mean only receiving bug fixes.

Can I suggest an alternative, pushing rolling release images to a different tag like :unstable or :dev, and only pushing to version images when a release is tagged (or to update the base image)? That way users can choose whether they would like the rolling release or stable release model. I hope this is not too much hassle.