diff mbox

librados: Bump the version to 0.48

Message ID 1341409564-26660-1-git-send-email-wido@widodh.nl (mailing list archive)
State New, archived
Headers show

Commit Message

Wido den Hollander July 4, 2012, 1:46 p.m. UTC
Signed-off-by: Wido den Hollander <wido@widodh.nl>
---
 src/include/rados/librados.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Gregory Farnum July 4, 2012, 4:29 p.m. UTC | #1
Hmmm — we generally try to modify these versions when the API changes, not on every sprint. It looks to me like Sage added one function in 0.45 where we maybe should have bumped it, but that was a long time ago and at this point we should maybe just eat it?
-Greg


On Wednesday, July 4, 2012 at 6:46 AM, Wido den Hollander wrote:

>  
> Signed-off-by: Wido den Hollander <wido@widodh.nl (mailto:wido@widodh.nl)>
> ---
> src/include/rados/librados.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>  
> diff --git a/src/include/rados/librados.h b/src/include/rados/librados.h
> index 9f723f7..4870b0f 100644
> --- a/src/include/rados/librados.h
> +++ b/src/include/rados/librados.h
> @@ -23,7 +23,7 @@ extern "C" {
> #endif
>  
> #define LIBRADOS_VER_MAJOR 0
> -#define LIBRADOS_VER_MINOR 44
> +#define LIBRADOS_VER_MINOR 48
> #define LIBRADOS_VER_EXTRA 0
>  
> #define LIBRADOS_VERSION(maj, min, extra) ((maj << 16) + (min << 8) + extra)
> --  
> 1.7.9.5
>  
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org (mailto:majordomo@vger.kernel.org)
> More majordomo info at http://vger.kernel.org/majordomo-info.html



--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Sage Weil July 4, 2012, 4:33 p.m. UTC | #2
On Wed, 4 Jul 2012, Gregory Farnum wrote:
> Hmmm ÿÿ we generally try to modify these versions when the API changes, 
> not on every sprint. It looks to me like Sage added one function in 0.45 
> where we maybe should have bumped it, but that was a long time ago and 
> at this point we should maybe just eat it?

Yeah, I went ahead and applied this to stable (argonaut) since it's as 
good a reference point as any.  Moving forward, we should try to sync 
this up with API changes as they happen.  Hmm, like that assert 
ObjectOperation that just went into master... 

sage
Wido den Hollander July 5, 2012, 7:26 a.m. UTC | #3
On 07/04/2012 06:33 PM, Sage Weil wrote:
> On Wed, 4 Jul 2012, Gregory Farnum wrote:
>> Hmmm ÿÿ we generally try to modify these versions when the API changes,
>> not on every sprint. It looks to me like Sage added one function in 0.45
>> where we maybe should have bumped it, but that was a long time ago and
>> at this point we should maybe just eat it?
>
> Yeah, I went ahead and applied this to stable (argonaut) since it's as
> good a reference point as any.  Moving forward, we should try to sync
> this up with API changes as they happen.  Hmm, like that assert
> ObjectOperation that just went into master...

That was my reasoning. I compiled phprados against 0.48 and saw that 
librados was reporting 0.44 as version.

That could confuse users and they might think they still have an old 
library in place.

Imho the version numbering should be totally different from Ceph if you 
only want to bump the version on an API change.

Wido

>
> sage
>

--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Gregory Farnum July 5, 2012, 10:33 p.m. UTC | #4
On Wed, Jul 4, 2012 at 9:33 AM, Sage Weil <sage@inktank.com> wrote:
> On Wed, 4 Jul 2012, Gregory Farnum wrote:
>> Hmmm ÿÿ we generally try to modify these versions when the API changes,
>> not on every sprint. It looks to me like Sage added one function in 0.45
>> where we maybe should have bumped it, but that was a long time ago and
>> at this point we should maybe just eat it?
>
> Yeah, I went ahead and applied this to stable (argonaut) since it's as
> good a reference point as any.  Moving forward, we should try to sync
> this up with API changes as they happen.  Hmm, like that assert
> ObjectOperation that just went into master...

Yep, should probably bump it to .49 then! (Since that's the version it
will be part of, and nobody will get confused and try to bump it again
before that release.)


On Thu, Jul 5, 2012 at 12:26 AM, Wido den Hollander <wido@widodh.nl> wrote:
> That was my reasoning. I compiled phprados against 0.48 and saw that
> librados was reporting 0.44 as version.
>
> That could confuse users and they might think they still have an old library
> in place.
>
> Imho the version numbering should be totally different from Ceph if you only
> want to bump the version on an API change.

Well, the problem with bumping it on every Ceph version is that it
becomes a lot harder for tools to sync up to a known version of the
API. Perhaps we should have divorced it from the Ceph versioning
completely, but I don't know if we can still do that in a reasonable
way or not. :/
-Greg
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Wido den Hollander July 6, 2012, 8:52 a.m. UTC | #5
On 07/06/2012 12:33 AM, Gregory Farnum wrote:
> On Wed, Jul 4, 2012 at 9:33 AM, Sage Weil <sage@inktank.com> wrote:
>> On Wed, 4 Jul 2012, Gregory Farnum wrote:
>>> Hmmm ÿÿ we generally try to modify these versions when the API changes,
>>> not on every sprint. It looks to me like Sage added one function in 0.45
>>> where we maybe should have bumped it, but that was a long time ago and
>>> at this point we should maybe just eat it?
>>
>> Yeah, I went ahead and applied this to stable (argonaut) since it's as
>> good a reference point as any.  Moving forward, we should try to sync
>> this up with API changes as they happen.  Hmm, like that assert
>> ObjectOperation that just went into master...
>
> Yep, should probably bump it to .49 then! (Since that's the version it
> will be part of, and nobody will get confused and try to bump it again
> before that release.)
>
>
> On Thu, Jul 5, 2012 at 12:26 AM, Wido den Hollander <wido@widodh.nl> wrote:
>> That was my reasoning. I compiled phprados against 0.48 and saw that
>> librados was reporting 0.44 as version.
>>
>> That could confuse users and they might think they still have an old library
>> in place.
>>
>> Imho the version numbering should be totally different from Ceph if you only
>> want to bump the version on an API change.
>
> Well, the problem with bumping it on every Ceph version is that it
> becomes a lot harder for tools to sync up to a known version of the
> API. Perhaps we should have divorced it from the Ceph versioning
> completely, but I don't know if we can still do that in a reasonable
> way or not. :/

You could always say: 0.48 was the "stable" release, from here on we are 
only going to bump the librados version if any API change happends.

Sent out an e-mail on the devel list and write a blogpost? I don't think 
we have a lot of developers using native librados at the moment.

Wido

> -Greg
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/src/include/rados/librados.h b/src/include/rados/librados.h
index 9f723f7..4870b0f 100644
--- a/src/include/rados/librados.h
+++ b/src/include/rados/librados.h
@@ -23,7 +23,7 @@  extern "C" {
 #endif
 
 #define LIBRADOS_VER_MAJOR 0
-#define LIBRADOS_VER_MINOR 44
+#define LIBRADOS_VER_MINOR 48
 #define LIBRADOS_VER_EXTRA 0
 
 #define LIBRADOS_VERSION(maj, min, extra) ((maj << 16) + (min << 8) + extra)