No. It is a normal build; any of which can be declared final after review of the build and agreement among the committers. After we declare a build final, we increment the version number in source control to being the next release cycle. For example, we are currently building version 3.0. Each build makes 3.0 versioned jars (the jar version is suffixed with the build timestamp also). One of the builds (when we are ready), will be declared the final 3.0 build and we will want to promote those built jars into the universe as the released 3.0 jars. We will then update the version in source control to 3.1 to start the next release cycle.
Well if a build on the CI system is declared the final build, I need to then get the built jar into repositories for consumers. With bintray and maven, I can publish that jar built in the CI build which was declared the final build (after it was built). Previously the gradle plugin portal used the jar from bintray, so this worked fine. With the new, plugin publishing plugin, I can’t publish a jar built elsewhere (like in my CI build) without some game playing or rebuilding (which defeats the point of declaring a build final after it is built).
Well, I don’t see it as part of a build. It is a discreet step after a build to promote a build artifact to a released status. I can work like this in bintray and maven (as we currently do). The bintray and maven models allow you to upload the artifact to a staging state, where it could be reviewed by others on the project, and then it is promoted to released.
The plugin publishing plugin model seems to encourage a work mode where either a developer builds and publishes from her workstation (which can result in binaries different than the CI built binaries) or having a special build on the CI system just to build and publish. This special build can have issues since it is infrequently used and thus can be out of date with the normal CI build.