mdedetrich commented on issue #339: URL: https://github.com/apache/incubator-pekko/issues/339#issuecomment-1561770068
I understand but I re-iterate my earlier point about it being largely ceremonial and hence its just adding extra steps. This was discussed either in the earlier thread or on the mailing list, but iirc there isn't any problem in creating our own release process which can just state "clone the git repository at this tag". Also the version just controls the filename of the jars being made, everything else about the build is the same. Again I don't really know if this breaks some ASF process, but one thing I have noticed on this journey is that a lot of "rules" are in fact just formalities/habits. If there is an actual rule that committers/IPMC verifying a release are not allowed to clone the git repo and check out a tag then I don't have a problem temporarily setting and deleting the version even though it basically kills the premise of sbt-dynver (which is that the git tag **is the source of truth**). Even in the case where checking out a git repository is not allowed, you can simply set the version when starting sbt, i.e. ```sh sbt "set ThisBuild / version := \"1.0.0\"; shell" ``` This force the version for the project before going into the standard sbt shell. You can also do ```sh sbt "set ThisBuild / version := \"1.0.0\"; publishLocal" ``` Which will publish the project with that version locally if you want to verify the jars and then exit. Another option is to do it the Akka/Pekko way and just pass it as a `-D` system flag, adding this functionality is just a few lines and it has precedent in other Pekko modules. Furthermore when we get the docker build up and running is to just pass a [build-arg](https://stackoverflow.com/a/34254700) to the Docker script which will pass it into sbt. So my preference is to cross that bridge when we get there, I am sure if this is an actual problem then we will be promptly told when doing the release. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
