You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "James E. King, III" <jk...@apache.org> on 2017/12/05 17:41:25 UTC

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

Re: Release procedures for third party package managers

Posted by Randy Abernethy <ra...@apache.org>.
I can help with some libs as well.

On Tue, Dec 5, 2017 at 11:06 AM, Jens Geyer <je...@hotmail.com> wrote:

> 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: dev@thrift.apache.org
> 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
>
>

Re: Release procedures for third party package managers

Posted by Jens Geyer <je...@hotmail.com>.
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: dev@thrift.apache.org
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