Hi Atin,
On 30/01/17 15:25, Atin Mukherjee wrote:
On Mon, Jan 30, 2017 at 7:30 PM, Xavier Hernandez <xhernandez@xxxxxxxxxx
<mailto:xhernandez@xxxxxxxxxx>> wrote:
Hi,
I'm wondering how a new option needs to be created to be available
to different versions of gluster.
When a new option is created for 3.7 for example, it needs to have a
GD_OP_VERSION referencing the next 3.7 release. This ensures that
there won't be any problem with previous versions.
However what happens with 3.8 ?
3.8.0 is greater than any 3.7.x, however the new option won't be
available until the next 3.8 release. How this needs to be handled ?
I'd discourage to backport any new volume options from mainline to the
stable releases branches like 3.7 & 3.8. This creates a lot of backward
compatibility issues w.r.t clients. Any new option is actually an RFE
and supposed to be slated for only upcoming releases.
Even if it's needed to solve an issue in all versions ?
For example, a hardcoded timeout is seen to be insufficient in some
configurations, so it needs to be increased, but increasing it will be
too much for many of the environments where the current timeout has
worked fine. It could even be not enough for other environments still
not tried, needed a future increase.
With a new option, this can be solved case by case and only when needed.
How can this be solved ?
Thanks,
Xavi
Thanks,
Xavi
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx <mailto:Gluster-devel@xxxxxxxxxxx>
http://lists.gluster.org/mailman/listinfo/gluster-devel
<http://lists.gluster.org/mailman/listinfo/gluster-devel>
--
~ Atin (atinm)
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel
