Making releases
Eric Evans
started following trunk. To avoid this, one option would be to put
Pycassa versions in lock-step with Cassandra, so that it's always
immediately obvious which version of Pycassa to use.
So in other words, as soon as Cassandra branches 0.7, Pycassa branches
as well. The master branch would continue to be the place for the
main development efforts, the stuff that is tracking changes to
Cassandra trunk. The new branch, let's call it "0.7" would correspond
to branches/cassandra-0.7 which would eventually be the basis for the
next Cassandra stable release. When that happens, we'd tag the "0.7"
branch and release Pycassa 0.7.0.
The one downside I see to this is that people may take it too
literally and assume for example that Cassandra 0.7.3 be matched
exactly to Pycassa 0.7.3, and think it a mismatch to use say Pycassa
0.7.1.
What does everyone else think?
--
Eric Evans
john.er...@gmail.com
Tyler Hobbs
be resolved.
I think the downside that you bring up is a pretty heavy
one.
I think a solution might be this: the pycassa version number
is the Cassandra version it supports plus a pycassa version
for that Cassandra version only.
So, while 0.7.0 is out, we might have:
- pycassa 0.7.0-1.0
- pycassa 0.7.0-2.0
:
- pycassa 0.7.0-9.2
But when Cassandra 0.8.0 comes out, we start with:
- pycassa 0.8.0-1.0
We might consider dropping the Cassandra "bugfix" version
from the numbering scheme, since that's unlikely to affect pycassa
greatly.
Thoughts?
- Tyler
Eric Evans
> I think a solution might be this: the pycassa version number
> is the Cassandra version it supports plus a pycassa version
> for that Cassandra version only.
>
> So, while 0.7.0 is out, we might have:
> - pycassa 0.7.0-1.0
> - pycassa 0.7.0-2.0
> :
> - pycassa 0.7.0-9.2
>
> But when Cassandra 0.8.0 comes out, we start with:
> - pycassa 0.8.0-1.0
I suppose it's bike-shedding at this point, but some projects use
letters, so you could have:
pycassa 0.7a
pycassa 0.7b
> On Tue, Aug 24, 2010 at 10:03 AM, Eric Evans <john.er...@gmail.com>
> wrote:
>>
>> There was (continues to be) some confusion after vomjom's master
>> started following trunk. To avoid this, one option would be to put
>> Pycassa versions in lock-step with Cassandra, so that it's always
>> immediately obvious which version of Pycassa to use.
>>
>> So in other words, as soon as Cassandra branches 0.7, Pycassa branches
>> as well. The master branch would continue to be the place for the
>> main development efforts, the stuff that is tracking changes to
>> Cassandra trunk. The new branch, let's call it "0.7" would correspond
>> to branches/cassandra-0.7 which would eventually be the basis for the
>> next Cassandra stable release. When that happens, we'd tag the "0.7"
>> branch and release Pycassa 0.7.0.
>>
>> The one downside I see to this is that people may take it too
>> literally and assume for example that Cassandra 0.7.3 be matched
>> exactly to Pycassa 0.7.3, and think it a mismatch to use say Pycassa
>> 0.7.1.
>>
>> What does everyone else think?
>>
>> --
>> Eric Evans
>> john.er...@gmail.com
>
>
--
Eric Evans
john.er...@gmail.com
Daniel Lundin
I don't think using dashes in the version is a good idea. RPMs use
dashes for package release versions, so it wouldn't fit well.
I think it'd be better to just tack on a fourth "level" to the
cassandra version.
cassandra 0.7.0 <-> pycassa 0.7.0.0
pycassa 0.7.0.1
pycassa 0.7.0.2
cassandra 0.7.1 <-> pycassa 0.7.1.0
pycassa 0.7.1.1
...
And so on
Although it might be a bit wordy using four-segment versions, it's
explicit and concise.
/d
On Aug 24, 7:24 pm, Tyler Hobbs <ty...@riptano.com> wrote:
> I agree that the confusion/compatibility issues need to
> be resolved.
>
> I think the downside that you bring up is a pretty heavy
> one.
>
> I think a solution might be this: the pycassa version number
> is the Cassandra version it supports plus a pycassa version
> for that Cassandra version only.
>
> So, while 0.7.0 is out, we might have:
> - pycassa 0.7.0-1.0
> - pycassa 0.7.0-2.0
> :
> - pycassa 0.7.0-9.2
>
> But when Cassandra 0.8.0 comes out, we start with:
> - pycassa 0.8.0-1.0
>
> We might consider dropping the Cassandra "bugfix" version
> from the numbering scheme, since that's unlikely to affect pycassa
> greatly.
>
> Thoughts?
> - Tyler
>
Tyler Hobbs
Given that, I think Eric's scheme using letters is the easiest way
to differentiate Cassandra and Pycassa versions.
The only question I have is: do we want to include the least-significant
Cassandra version number or not?
0.7.1a (or 0.7.1.a)
or
0.7a (or 0.7.a)
I wasn't paying much attention to 0.6, but how different were each
of the 0.6.x versions?
Jon Hermes
I like my bikeshed green with large, solid doors and I like my versioning to be as exact as possible, even at the cost of a longer string. +1 pycassa-0.7.1z
On Aug 24, 2010 1:19 PM, "Tyler Hobbs" <ty...@riptano.com> wrote:
Daniel, I think you're right about not using dashes in the version.
Given that, I think Eric's scheme using letters is the easiest way
to differentiate Cassandra and Pycassa versions.
The only question I have is: do we want to include the least-significant
Cassandra version number or not?
0.7.1a (or 0.7.1.a)
or
0.7a (or 0.7.a)
I wasn't paying much attention to 0.6, but how different were each
of the 0.6.x versions?
On Tue, Aug 24, 2010 at 1:03 PM, Daniel Lundin <d...@eintr.org> wrote:
>
> Excellent idea.
>
> I do...
Eric Evans
>
> I don't think using dashes in the version is a good idea. RPMs use
> dashes for package release versions, so it wouldn't fit well.
Right.
> I think it'd be better to just tack on a fourth "level" to the
> cassandra version.
>
> cassandra 0.7.0 <-> pycassa 0.7.0.0
> pycassa 0.7.0.1
> pycassa 0.7.0.2
> cassandra 0.7.1 <-> pycassa 0.7.1.0
> pycassa 0.7.1.1
Except API changes don't go into Cassandra stable releases so
incrementing the third member in a Pycassa release would really
confuse matters. In other words, with respect to Pycassa
compatibility, all "0.7" versions would be compatible with Cassandra
0.7.N, for all possible values of N.
--
Eric Evans
john.er...@gmail.com
Eric Evans
given your complete failure to assess a proper color and disposition
for the bikeshed.
Green... madness!
--
Eric Evans
john.er...@gmail.com
Tyler Hobbs
going with:
0.7a
0.7b
0.7c
:
0.8a
etc
Done?
- Tyler
Jon Hermes
Say the api doesn't change, but the implementation of method X differs and pycassa is updated to call the (now much faster) X instead of a series of Y calls. To be more specific, say multiget() returns in-order instead of unordered and we change pycassa to accomodate it.
Now the change is between, say, cassandra-0.7.0 and cassandra-0.7.1, both stable releases. We need to match pycassa versions or bad things will happen, so be explicit. pycassa-0.7.0a and pycassa-0.7.1a. It's easy to ignore the designation and makes the releases look crappy if you add it in later.
AND the shed is green so when you mow grass in your back yard, it doesn't leave a hideous line on a non-green shed!
On Aug 24, 2010 1:41 PM, "Eric Evans" <john.er...@gmail.com> wrote:
I'm sorry, I'm compelled to disregard your opinions on version numbers
given your complete failure to assess a proper color and disposition
for the bikeshed.
Green... madness!
On Tue, Aug 24, 2010 at 1:31 PM, Jon Hermes <jon.p....@gmail.com> wrote:
> I like my bikeshed gr...
--
Eric Evans
john.er...@gmail.com
Tyler Hobbs
we drop support for old branches fairly quickly, this might not be too bad, though.
So, for example, we might drop maintenance for 0.6.0x - 0.6.3x quickly, leave 0.6.4x
around for a longer time, and (assuming 0.6.5 is the last 0.6 cassandra) maintain
0.6.5x versions much longer.
Eric Evans
> Say the api doesn't change, but the implementation of method X differs and
> pycassa is updated to call the (now much faster) X instead of a series of Y
> calls. To be more specific, say multiget() returns in-order instead of
> unordered and we change pycassa to accomodate it.
>
> Now the change is between, say, cassandra-0.7.0 and cassandra-0.7.1, both
> stable releases. We need to match pycassa versions or bad things will
> happen, so be explicit. pycassa-0.7.0a and pycassa-0.7.1a. It's easy to
> ignore the designation and makes the releases look crappy if you add it in
> later.
If something like this were to happen then I'd rather see something
that evaluated the API version returned from the node and selectively
apply the optimization, rather than burden users with matching the
right minor version of the client to the right minor version of
Cassandra.
> AND the shed is green so when you mow grass in your back yard, it doesn't
> leave a hideous line on a non-green shed!
Whoa! When did the bikeshed get in the back yard?
--
Eric Evans
john.er...@gmail.com
Tyler Hobbs
Then why don't we drop the least-significant Cassandra version for now, and
if something comes up where we really need to designate that cassandra version,
we will have a special-case and include it. Perhaps it might be ugly, but I think we can
do something like what Eric says in most cases.
Jon Hermes
Yeah, that's fine.
"pycassa-0.7a is the typical case. pycassa-0.7.1a if something goes wrong. there is no guarantee of compat. between pycassa-Xa and pycassa-Xb."
On Aug 24, 2010 3:30 PM, "Tyler Hobbs" <ty...@riptano.com> wrote:
*sigh*
Then why don't we drop the least-significant Cassandra version for now, and
if something comes up where we really need to designate that cassandra version,
we will have a special-case and include it. Perhaps it might be ugly, but I think we can
do something like what Eric says in most cases.
On Tue, Aug 24, 2010 at 2:19 PM, Eric Evans <john.er...@gmail.com> wrote:
>
> On Tue, Aug 24,...
Daniel Lundin
/d
Tyler Hobbs
to keep the versioning in lock-step with Cassandra. Sorry! :)
The reason is that I think the Thrift API has stabilized enough that
it won't be hard to provide support for multiple Cassandra versions
from here on out. I would rather users not assume that an "0.8"
version is not backwards-compatible with 0.7 Cassandra, for example.
- Tyler