Hi Nick, thanks for that clarification. However, if you take this formal, then the docker containers are not releases or part of the project release anyway because they are not available on downloads.apache.org – violating “all artifacts MUST be uploaded to the project's subdirectory within the canonical Apache distribution channel, downloads.apache.org.”
More seriously, a clear naming convention as outlined under <http://www.apache.org/legal/release-policy.html#release-types> http://www.apache.org/legal/release-policy.html#release-types should do. You could outline the tag naming conventions in the documentation available in the docker repository. And last but not least, as long as an artifact like docker containers consumes upstream projects that are less rigid, any release decision is based on limited knowledge – unless you encourage early testing in as many scenarios as possible – and one way to encourage that is via nightly builds or containers. Involving lawyers may complicate the matter significantly of course, and I guess you have to… Best Regards, Joachim Von: Nick Couchman <[email protected]> Gesendet: Samstag, 9. Mai 2020 16:25 An: [email protected] Betreff: Re: Docker automated builds? On Sat, May 9, 2020 at 9:27 AM Joachim Lindenberg <[email protected] <mailto:[email protected]> > wrote: Hello Team, is there any reason why you don´t leverage automated builds on docker hub? The benefit I see is that testing bug fixes or even testing with newer builds more frequently would become easier if I don´t need to pull the source and build on my own but can just reference a different tag. As “latest” is usually used for the most recent released version, you could pick the branch name, or “nightly” or whatever. As an experiment, I forked guacamole-server on github and configured a docker hub build against that, and it worked with the default build rule except that I changed latest to master in second iteration. I did a smoke test and it appears to work. However, afaik there is no means on github to force a fork to mirror the source repository automatically, nor can I configure a docker hub build against a repository owned by someone else. Thus getting a nightly build would involve extra script code to sync the fork, which would be unnecessary if you configure it. Thanks for your consideration. Best Regards, Joachim At least one of the reasons for this is that the Apache Foundation highly discourages this: http://www.apache.org/legal/release-policy.html You can read about their reasoning for this, but, essentially, they want the projects to make sure there is a clear distinction between official released versions and development builds, particularly for users/non-developers. -Nick
