Hi > Should the "dist" CI build produce these so we can > take them directly from the CI system
That would be my favourite choice. That way we have a defined process which is ideally free of manual work. Creating these artifacts should also be a standard CI task, if possible, to make sure it works when we need it. Aside from getting it reproducable, I personally have not ever in my life used CPAN (to name just one). And I certainly don't want to do this, or deal with 10 other languages' package managers that I don't know much about. I can cover a few where I have appropriate knowledge, but not everything. And I guess that this will be the case with most people around. That's by the way also one reason why I didn't provide prebuilt libs. The other reason is that they are not part of the official release binaries anyway, at least that's how we did it in the past. $0,02, JensG -----Ursprüngliche Nachricht----- From: James E. King, III Sent: Tuesday, December 5, 2017 6:41 PM To: [email protected] Subject: Release procedures for third party package managers Once Thrift 0.11.0 is complete and released, I will build it and upload it to CPAN. I have a question however about how we manage the official releases to third party packagers... I believe there is likely to be one per language at this point, but I'm not certain as a project we take any official capacity to upload and maintain an official package to these. For example there's node.js npm, and there's perl CPAN, and there rust cargo. Should the official build process for Thrift also include creation and dissemination of official third party package manager releases? Should the "dist" CI build produce these so we can take them directly from the CI system, or perhaps mark them as artifacts that need to be captured on a specially named branch (like release/), such that any build on that branch would build and capture third party package manager artifacts for dissemination? Thanks, - Jim
