[Gluster-devel] Stable numbering of RPC procedures

[Amar Tumballi]

On 06/17/2013 02:39 PM, Niels de Vos wrote:
> On Fri, Jun 14, 2013 at 12:07:51PM -0700, Anand Avati wrote:
>> On Fri, Jun 14, 2013 at 1:40 AM, Bharata B Rao <bharata.rao at gmail.com>wrote:
>>
>>> On Mon, Jun 3, 2013 at 9:12 PM, Anand Avati <anand.avati at gmail.com> wrote:
>>>> This looks more like a compile time feature check than runtime. The
>>>> PKG_CONFIG() api number which had the initial set of QEMU requirements
>>> was 3
>>>> (i.e, PKG_CONFIG(..,glusterfs-api>=3,..). The new updates for Samba
>>>> requirements has api number 4. Depending on whether discard support
>>> makes it
>>>> before the next release (and api numbers gets published) or not,
>>>> glfs_discard() would either be available in 4 or 5. Also, you might also
>>>> want to add a second AC_CHECK_FUNC macro in configure.ac to be doubly
>>> sure.
>>>
>>> Now with fallocate and discard support upstream, are you planning to
>>> increment the glusterfs-api version ? I still see the version as 4 in
>>> the git master. I need to decide if I should use version 4 or 5 to
>>> determine the availability of discard support from QEMU.
>>>
>>
>>
>> This is yet to be determined. The fallocate/discard introduces change in
>> the internal protocol/rpc and we're figuring out the right time to bring
>> this patch into a release branch. Since release-3.4 is still "unreleased"
>> there is a possibility, but we have not yet decided on it.
>
> I've just looked at the latest additions to the protocol/rpc procedures.
> If these changes have not made it to a release, please consider
> including this change first:
> - http://review.gluster.org/5215
>
> Currently posted as RFC, no Bug yet. Let me know if this change is still
> possible, and I'll file a Bug and repost. I'll await your response
> before sending patches to the Wireshark project. (I need to know that
> the number of the new RPC procedures is stable.)
>

I looked at initial patch and the new one. Adding it to the end of the 
procedure list is surely better than adding them at the middle. But, in 
long run, its not good to make changes to existing version number 
itself. Any new changes to released RPC program spec should happen with 
bump in program version number.

-Amar