You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Dan Fabulich <da...@fabulich.com> on 2009/03/07 23:45:11 UTC
[DBUTILS] Version numbering (was: Java version not specified in
POM)
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 we call the java5 version "1.3"? That would
certainly save time on branch management...?
sebb wrote:
> The pom.xml does not specify a java source or target version, so
> defaults to 1.3 (from the parent pom)
>
> As far as I can tell, the component requires at least 1.4 so the POM
> needs to be updated.
>
> [IMO the compiler settings should never be delegated to the parent POM]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBUTILS] Version numbering
Posted by Stephen Colebourne <sc...@btopenworld.com>.
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 argument that wants the package names changed for each
> major version.
The package name only needs to change if the new version is backwards
binary incompatible.
The definition is that two (or more) other open source projects
depending on the same commons project must be able to upgrade at
separate times without impacting users.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBUTILS] Version numbering (was: Java version not specified in
POM)
Posted by James Carman <ja...@carmanconsulting.com>.
On Sat, Mar 7, 2009 at 10:26 PM, Dan Fabulich <da...@fabulich.com> 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 difference.
>
> If that lets us call it "dbutils 1.3" and avoid extra branching work, that'd
> be great.
Calling it 2.0 (and thus changing the package name) does give you more
freedom, too (remove some clutter, simplify the API, etc.). Let's not
forget that. Of course, that could be done post-varargs/generics.
I'm not completely familiar with the API, but usually when you
introduce a varargs method, you're replacing an existing array method
along with a one, two, and three-argument method. I don't think those
sort of changes are backward compatible (existing code would have
"pointed" at the two-argument method for instance). Again, I don't
know that's the case, but just wanted to make sure.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBUTILS] Version numbering
Posted by James Carman <ja...@carmanconsulting.com>.
Yep, branches are cheap. This is a good approach!
On Mon, Mar 9, 2009 at 11:35 AM, Henri Yandell <fl...@gmail.com> 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, 2009 at 7:43 AM, Liam Coughlin <ls...@gmail.com> wrote:
>> 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 java 5 "Now with Special Sauce but the Same
>> Old Hamburger" release would be all that useful in the long run, but i could
>> be completely wrong.
>>
>> Cheers,
>> -L
>>
>>
>>
>> n@fabulich.com <da...@fabulich.com>> 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.
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBUTILS] Version numbering
Posted by Henri Yandell <fl...@gmail.com>.
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 <ls...@gmail.com> wrote:
> 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 java 5 "Now with Special Sauce but the Same
> Old Hamburger" release would be all that useful in the long run, but i could
> be completely wrong.
>
> Cheers,
> -L
>
>
>
> n@fabulich.com <da...@fabulich.com>> 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.
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBUTILS] Version numbering
Posted by Liam Coughlin <ls...@gmail.com>.
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 java 5 "Now with Special Sauce but the Same
Old Hamburger" release would be all that useful in the long run, but i could
be completely wrong.
Cheers,
-L
n@fabulich.com <da...@fabulich.com>> 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.
>
>
Re: [DBUTILS] Version numbering
Posted by James Carman <ja...@carmanconsulting.com>.
On Sun, Mar 8, 2009 at 10:45 PM, Dan Fabulich <da...@fabulich.com> 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. Don't leave too many folks out in
the cold. Good thinking!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBUTILS] Version numbering
Posted by Dan Fabulich <da...@fabulich.com>.
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 dbutils 1.3 with generics and varargs followed
shortly afterward by a more thoroughly re-worked dbutils 2.0.
-Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBUTILS] Version numbering
Posted by Liam Coughlin <ls...@gmail.com>.
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 <
scolebourne@btopenworld.com> wrote:
> 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
>> 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 difference.
>>
>
> Check javap method signatures, or use clirr.
>
>
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [DBUTILS] Version numbering
Posted by Stephen Colebourne <sc...@btopenworld.com>.
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 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 difference.
Check javap method signatures, or use clirr.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBUTILS] Version numbering (was: Java version not specified in
POM)
Posted by Dan Fabulich <da...@fabulich.com>.
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 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 difference.
If that lets us call it "dbutils 1.3" and avoid extra branching work,
that'd be great.
-Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBUTILS] Version numbering (was: Java version not specified in
POM)
Posted by Henri Yandell <fl...@gmail.com>.
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 package names changed for each
major version.
Hen
On Sat, Mar 7, 2009 at 2:45 PM, Dan Fabulich <da...@fabulich.com> wrote:
> 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 we call the java5 version "1.3"? That would
> certainly save time on branch management...?
>
> sebb wrote:
>
>> The pom.xml does not specify a java source or target version, so
>> defaults to 1.3 (from the parent pom)
>>
>> As far as I can tell, the component requires at least 1.4 so the POM
>> needs to be updated.
>>
>> [IMO the compiler settings should never be delegated to the parent POM]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org