I think we should continue with the original plan: Bug fixes go into the patch
level version. New features go into minor releases. Changes to the
architecture
or APIs should go into the next major release. By having this clear
delineation, for example, those on 7.1.x know what to expect out
+1 - well said
I prefer #2.
-Bryan
> On Feb 7, 2018, at 7:20 PM, Masaori Koshiba wrote:
>
> Hi,
>
> It looks like #1 violate the Semantic Versioning(*1) which we're following
> now. Do we really stop following the versioning?
> IMO, we should keep following it, becasue it's easy to indicate t
+1 (non-binding) for #2
Steven's description seems reasonable to me also.
On Thu, Feb 8, 2018 at 11:26 AM, Bryan Call wrote:
> +1 - well said
>
> I prefer #2.
>
> -Bryan
>
> > On Feb 7, 2018, at 7:20 PM, Masaori Koshiba wrote:
> >
> > Hi,
> >
> > It looks like #1 violate the Semantic Versionin
I prefer #2. If we started backporting new features to 7.1.x branche, the
branch would be something like another master that doesn't break
compatibility, which means it'll be unstable all the time.
I'd like to hear opinions from people who supports #1. What we need to
discuss might not be "which v
Hey, I had a question about your cache architecture documentation: the docs say
that a span block header (DiskVolBlock) stores the length of the span block ‘in
store blocks’ as a uint64_t. What’s a store block? I’ve noted that the length
divided by the size of my one volume on the one cache file
