Yep, branches are cheap. This is a good approach!
On Mon, Mar 9, 2009 at 11:35 AM, Henri Yandell wrote:
> My strategy with Lang btw is to just develop it and see what the API
> looks like at the end. We spend too much time worrying about the
> version number up front :)
>
> Hen
>
> On Mon, Mar 9
My strategy with Lang btw is to just develop it and see what the API
looks like at the end. We spend too much time worrying about the
version number up front :)
Hen
On Mon, Mar 9, 2009 at 7:43 AM, Liam Coughlin wrote:
> That makes a little more sense then how I read the Stephen originally, and
>
That makes a little more sense then how I read the Stephen originally, and
yes you're probably right -- though I don't think you're going to be able to
get much varargs in without wrecking binary anyway since a lot of the
parameter ordering doesn't lend itself to it.
I just don't feel that a 1.3 j
On Sun, Mar 8, 2009 at 10:45 PM, Dan Fabulich wrote:
> "NEEDS" is a little strong I think there's room in the world for a
> backwards-compatible dbutils 1.3 with generics and varargs followed shortly
> afterward by a more thoroughly re-worked dbutils 2.0.
That sounds like a good approach. D
Liam Coughlin wrote:
the code NEEDS to change though, and not in a backwards compatible way. Do
whatever is appropriate with version numbers to indicate that non-binary
compatible changes are coming.
"NEEDS" is a little strong I think there's room in the world for a
backwards-compatible
the code NEEDS to change though, and not in a backwards compatible way. Do
whatever is appropriate with version numbers to indicate that non-binary
compatible changes are coming.
Cheers,
-L
On Sun, Mar 8, 2009 at 6:04 AM, Stephen Colebourne <
scolebou...@btopenworld.com> wrote:
> Dan Fabulich w
Dan Fabulich wrote:
Henri Yandell wrote:
The Java5 version is more up for debate. If the API is no longer
compatible, then we start to lean to 2.0. Especially as calling it 2.0
allows for more of an overhaul of API.
The the API in the "java5" branch is backward compatible; the generics
and v
On Sat, Mar 7, 2009 at 10:26 PM, Dan Fabulich wrote:
> The the API in the "java5" branch is backward compatible; the generics and
> varargs are erased at compile time. Of course, the code has to be compiled
> with target=1.5, but on a Java 1.5 VM you could swap it in and not notice
> the differen
Henri Yandell wrote:
The Java5 version is more up for debate. If the API is no longer
compatible, then we start to lean to 2.0. Especially as calling it 2.0
allows for more of an overhaul of API.
The the API in the "java5" branch is backward compatible; the generics and
varargs are erased at
Henri Yandell wrote:
I believe we can call it 1.2 - as long as it's API compatible then tis good.
The Java5 version is more up for debate. If the API is no longer
compatible, then we start to lean to 2.0. Especially as calling it 2.0
allows for more of an overhaul of API.
There's also an argume
I believe we can call it 1.2 - as long as it's API compatible then tis good.
The Java5 version is more up for debate. If the API is no longer
compatible, then we start to lean to 2.0. Especially as calling it 2.0
allows for more of an overhaul of API.
There's also an argument that wants the packa
Good catch. :-(
Uh, if dbutils 1.1 was compatible with java 1.3, and we want to depend on
java 1.4 in the next version, do we have to call it "dbutils 2.0"?
I assume not; I think we can still call it "dbutils 1.2" even though we
depend on java 1.4 now. Is that OK?
Similarly, could/should
12 matches
Mail list logo
