Have you thought about using ldflags to pass git commit or git tag which
can be the actual version. This will tie into a build system automatically
without additional files. We don't have to maintain the version
information in git and a separate file.
Here is an example.
https://stackoverflow.com/q
+1 non binding
> On Feb 10, 2022, at 6:37 PM, Neng Lu wrote:
>
> +1 non-binding
>
> On Wed, Feb 9, 2022 at 6:46 PM Matteo Merli wrote:
>
>> +1
>>
>>
>> --
>> Matteo Merli
>>
>>
>> On Wed, Feb 9, 2022 at 6:44 PM r...@apache.org
>> wrote:
>>>
>>> Hello Everyone:
>>>
>>>
>>> I hope you’v
+1
Thanks
Ming
On Mon, 19 Jul 2021 at 18:55, Neng Lu wrote:
> +1
>
> Neng Lu
>
> On 2021/07/19 08:44:11 "r...@apache.org" wrote:
> > Hello Everyone:
> >
> > I hope you’ve all been doing well. In the past two months, we have
> > fixed a number of bugs related to connection leaks and added
> > so
+1
Xiaolong,
Thank you for organizing this. Is there any additional regression for 0.4.0
release? There were a few bug fixes around concurrency issues that were
introduced in earlier releases. We probably need more tests to cover.
Also can you confirm whether these three open PR (from the link)
+1
Are we doing additional testing for each release as supposed to each PR's
CI test?
On Fri, 12 Jun 2020 at 05:41, xiaolong ran wrote:
> Hi everyone,
>
> Please review and vote on the release candidate #1 for the version 0.1.1,
> as follows:
> [ ] +1, Approve the release
> [ ] -1, Do not approv
Hi Sijie,
I just want to clarify if it is to upgrade protobuf 2 to 3. Would that lead
to a backward compatibility issue for clients? Proto3 has removed the
custom default, which pulsar api proto uses, and a few others in proto 2.
Would that be a concern for clients?
Ming
On Fri, 22 May 2020 at 1
Hi,
Thanks for Sijie's proposal. I resonate Rajan's comment that this project
should become a peripheral to Pulsar because of the stateless nature of
HTTP and scaling up a web service inside Pulsar might be affecting
its current design. For that reason, I developed a project with an HTTP
interface
Hi,
Would PIP 55 propose how the client side plugin can implement a
credential/token refresh mechanism? The use case would be the client
proactively refresh the bearer token before disconnected due to expiration
by the broker.
I am thinking some additions to Authentication/AuthenticationDataProv
