You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by William Speirs <ws...@apache.org> on 2013/05/10 22:23:36 UTC
[DBUTILS] Pre RC for DBUTILS-2.0
Consider this a pre release candidate for DBUTILS-2.0. I fixed the
following things from RC1:
- Removed @author tags
- Changed QueryRunner to be public
- Made ArrayHandler generic (but it's ugly because I just cast to T[], does
anyone have a better idea here?)
If folks (*cough* Benedikt Ritter, *cough* Emmanuel Bourg, *cough* Sebb)
take a look and let me know what else needs to be changed before I go
through the whole RC process, that would be greatly appreciated.
Also, when I do cut an RC, how do I know what dates to fill in for the
changes.xml document? I won't know when the release will happen, and I'm
not sure about the 1.6 release either. Thoughts?
Thanks in advance...
Bill-
Re: [DBUTILS] Pre RC for DBUTILS-2.0
Posted by Benedikt Ritter <br...@apache.org>.
2013/5/13 Emmanuel Bourg <eb...@apache.org>
> Le 13/05/2013 21:24, William Speirs a écrit :
> >
> > Yes, I did mean QueryExecutor... sorry. I make my methods protected
> rather
> > than private because I'm not sure how someone (maybe myself) will need to
> > change functionality in the future. If I make them private, then there's
> > not going back. If I make them protected, someone can always extend and
> > provide new functionality. I'm open to other suggestions/ideas though.
>
> Actually it's the opposite. With protected methods there is no going
> back. Binary compatibility dictates that these methods will stay there
> forever, you won't be able to refactor them unlike private methods. You
> can still relax the constraint later by making them protected or public
> if the need arises.
>
>
> > Yes... but to what advantage?
>
> The advantage is an API that is cleaner and easier to understand.
>
>
> > It is more "generous" in finding a matching name in the bean for a
> column.
> > It will try to remove underscores from column names to match bean names.
> > Maybe a better name would/could be UnderscoreAgnosticBeanHandler, but I
> > think the idea was to eventually extend GenerousBeanProcessor to include
> an
> > array (or string) of single characters that could be replaced/removed in
> an
> > attempt to find a match. I don't think this needs to be a blocker though
> to
> > get 2.0 out the door. I'll update the JavaDocs though.
>
> Some examples in the Javadoc would help.
>
> As for the name, what about "SmartBeanProcessor" or
> "ImprovedBeanProcessor" (much like the ImprovedNamingStrategy in
> Hibernate) ? If this implementation is much better than the one in
> BeanProcessor, maybe it could be merged with BeanProcessor to be used by
> default?
>
+1 from a user POV why should you ever use the impl that is not smart or
improved ;-)
>
> Emmanuel Bourg
>
>
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [DBUTILS] Pre RC for DBUTILS-2.0
Posted by sebb <se...@gmail.com>.
On 13 May 2013 21:30, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 13/05/2013 21:24, William Speirs a écrit :
>>
>> Yes, I did mean QueryExecutor... sorry. I make my methods protected rather
>> than private because I'm not sure how someone (maybe myself) will need to
>> change functionality in the future. If I make them private, then there's
>> not going back. If I make them protected, someone can always extend and
>> provide new functionality. I'm open to other suggestions/ideas though.
>
> Actually it's the opposite. With protected methods there is no going
> back. Binary compatibility dictates that these methods will stay there
> forever, you won't be able to refactor them unlike private methods. You
> can still relax the constraint later by making them protected or public
> if the need arises.
+1
>
>> Yes... but to what advantage?
>
> The advantage is an API that is cleaner and easier to understand.
>
+1
>
>> It is more "generous" in finding a matching name in the bean for a column.
>> It will try to remove underscores from column names to match bean names.
>> Maybe a better name would/could be UnderscoreAgnosticBeanHandler, but I
>> think the idea was to eventually extend GenerousBeanProcessor to include an
>> array (or string) of single characters that could be replaced/removed in an
>> attempt to find a match. I don't think this needs to be a blocker though to
>> get 2.0 out the door. I'll update the JavaDocs though.
>
> Some examples in the Javadoc would help.
>
> As for the name, what about "SmartBeanProcessor" or
> "ImprovedBeanProcessor" (much like the ImprovedNamingStrategy in
> Hibernate) ? If this implementation is much better than the one in
> BeanProcessor, maybe it could be merged with BeanProcessor to be used by
> default?
>
> Emmanuel Bourg
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBUTILS] Pre RC for DBUTILS-2.0
Posted by William Speirs <ws...@apache.org>.
On Mon, May 13, 2013 at 4:30 PM, Emmanuel Bourg <eb...@apache.org> wrote:
>
> The advantage is an API that is cleaner and easier to understand.
>
I changed the methods to be package private.
> As for the name, what about "SmartBeanProcessor" or
> "ImprovedBeanProcessor" (much like the ImprovedNamingStrategy in
> Hibernate) ? If this implementation is much better than the one in
> BeanProcessor, maybe it could be merged with BeanProcessor to be used by
> default?
>
This could be merged into the BeanProcessor by simply adding a constructor
that takes a char (or array of chars) that are excluded when performing
column to bean property matching. This would leave the interface to the
BeanProcessor essentially the same, but add this functionality. If this is
the plan though, I'd add it to both the 1.x and 2.x branches.
Thoughts?
Bill-
Re: [DBUTILS] Pre RC for DBUTILS-2.0
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 13/05/2013 21:24, William Speirs a écrit :
>
> Yes, I did mean QueryExecutor... sorry. I make my methods protected rather
> than private because I'm not sure how someone (maybe myself) will need to
> change functionality in the future. If I make them private, then there's
> not going back. If I make them protected, someone can always extend and
> provide new functionality. I'm open to other suggestions/ideas though.
Actually it's the opposite. With protected methods there is no going
back. Binary compatibility dictates that these methods will stay there
forever, you won't be able to refactor them unlike private methods. You
can still relax the constraint later by making them protected or public
if the need arises.
> Yes... but to what advantage?
The advantage is an API that is cleaner and easier to understand.
> It is more "generous" in finding a matching name in the bean for a column.
> It will try to remove underscores from column names to match bean names.
> Maybe a better name would/could be UnderscoreAgnosticBeanHandler, but I
> think the idea was to eventually extend GenerousBeanProcessor to include an
> array (or string) of single characters that could be replaced/removed in an
> attempt to find a match. I don't think this needs to be a blocker though to
> get 2.0 out the door. I'll update the JavaDocs though.
Some examples in the Javadoc would help.
As for the name, what about "SmartBeanProcessor" or
"ImprovedBeanProcessor" (much like the ImprovedNamingStrategy in
Hibernate) ? If this implementation is much better than the one in
BeanProcessor, maybe it could be merged with BeanProcessor to be used by
default?
Emmanuel Bourg
Re: [DBUTILS] Pre RC for DBUTILS-2.0
Posted by William Speirs <ws...@apache.org>.
> You mean QueryExecutor, right? Now it's in line with UpdateExecutor and
> InsertExecutor, but I feel a bit uncomfortable with theses classes as
> they mostly expose protected methods and don't look like they are meant
> to be extended.
>
Yes, I did mean QueryExecutor... sorry. I make my methods protected rather
than private because I'm not sure how someone (maybe myself) will need to
change functionality in the future. If I make them private, then there's
not going back. If I make them protected, someone can always extend and
provide new functionality. I'm open to other suggestions/ideas though.
> Would it be possible to make the protected method in AbstractExecutor
> package private?
>
Yes... but to what advantage?
> Regarding the GenerousBeanProcessor class I still don't understand its
> name :) I think a more detailed Javadoc would be welcome.
>
It is more "generous" in finding a matching name in the bean for a column.
It will try to remove underscores from column names to match bean names.
Maybe a better name would/could be UnderscoreAgnosticBeanHandler, but I
think the idea was to eventually extend GenerousBeanProcessor to include an
array (or string) of single characters that could be replaced/removed in an
attempt to find a match. I don't think this needs to be a blocker though to
get 2.0 out the door. I'll update the JavaDocs though.
Thanks for the feedback!
Bill-
Re: [DBUTILS] Pre RC for DBUTILS-2.0
Posted by Emmanuel Bourg <eb...@apache.org>.
Hi Bill,
Le 10/05/2013 22:23, William Speirs a écrit :
> - Changed QueryRunner to be public
You mean QueryExecutor, right? Now it's in line with UpdateExecutor and
InsertExecutor, but I feel a bit uncomfortable with theses classes as
they mostly expose protected methods and don't look like they are meant
to be extended.
Would it be possible to make the protected method in AbstractExecutor
package private?
> - Made ArrayHandler generic (but it's ugly because I just cast to T[], does
> anyone have a better idea here?)
As long as it makes the API easier to use I don't think it really matters.
Regarding the GenerousBeanProcessor class I still don't understand its
name :) I think a more detailed Javadoc would be welcome.
Emmanuel Bourg
Re: [DBUTILS] Pre RC for DBUTILS-2.0
Posted by sebb <se...@gmail.com>.
On 11 May 2013 15:09, William Speirs <ws...@apache.org> wrote:
> Obviously up for debate, but are my updated thoughts:
>
> - release 2.0 from its own branch (starting with a new changes.xml file)
> - release 1.6 from trunk with the changes.xml file only including 1.x stuff
> - migrate 1.x into its own branch, and 2.0 into trunk
> - only release 1.x fixes if absolutely needed (this will probably never
> happen as 1.4 was 2 years after 1.3, and 1.5 a year after 1.4)
>
> Does this sound reasonable to everyone?
+1
> Bill-
>
>
> On Sat, May 11, 2013 at 8:56 AM, sebb <se...@gmail.com> wrote:
>
>> On 11 May 2013 13:21, Gary Gregory <ga...@gmail.com> wrote:
>> > OK, then you need to keep 1.6 so we do not loose the history.
>> >
>> > 2.0 should also include all fixes from 1.6.
>> >
>> > Do you plan on working on 2.0 and 1.6 in parallel? If not, I'd just
>> finish
>> > 1.6, then do the big changes for 2.0, all from trunk.
>> >
>> > Otherwise, you'll need a 1.6 branch and do 2.0 in trunk, or the other way
>> > around.
>>
>> That is the status quo: trunk is 1.6 and there is a branch for 2.0.
>>
>> Note that these have different Maven coordinates and different package
>> names.
>>
>> Effectively they are two different products.
>> This is fine, as 2.0 is a major rewrite.
>>
>> > But eventually, I think we'll want 2.0 in trunk. You'd also need to
>> > port any fixes you want for 1.6 from 2.0. Unless 1.6 is a more limited
>> > release that will not carry applicable fixes from 2.0.
>> >
>> > If it were me, I'd keep it simple and do 1.6, then 2.0, from trunk. ;)
>>
>> Not simple if there is any need to maintain the two incompatible versions.
>>
>> > Gary
>> >
>> >
>> > On Sat, May 11, 2013 at 8:13 AM, William Speirs <ws...@apache.org>
>> wrote:
>> >
>> >> It is and isn't up to date. There will be a 1.6 which will include big
>> >> fixes. However 2.0 is a major rewrite. So I think the proper course of
>> >> action is to remove the 1.6 lines from the changes file in the 2.0
>> branch,
>> >> but leave them in the 1.x branch (trunk). Then when I get around to
>> pushing
>> >> 1.6 it should all "work."
>> >>
>> >> Bill-
>> >> On May 11, 2013 8:09 AM, "Gary Gregory" <ga...@gmail.com> wrote:
>> >>
>> >> > On Sat, May 11, 2013 at 7:34 AM, William Speirs <ws...@apache.org>
>> >> > wrote:
>> >> >
>> >> > > OK, so then for the 2.0 release I'd just remove the 1.6 lines?
>> >> > >
>> >> >
>> >> > No. Based on changes.xml, It sounds like we were going to have a 1.6,
>> but
>> >> > now we are calling it 2.0. So you'd change the 1.6 to 2.0.
>> >> >
>> >> > But... right now I see the line's description as 'Bugfixes and
>> addition
>> >> of
>> >> > insert methods' which would not warrant a major version change.
>> >> >
>> >> > A major version would suggest a large change or binary
>> incompatibility,
>> >> > which is not noted in the changes.xml file. Is this file up to date?
>> >> >
>> >> > Gary
>> >> >
>> >> > >
>> >> > > Bill-
>> >> > > On May 10, 2013 5:37 PM, "Gary Gregory" <ga...@gmail.com>
>> >> wrote:
>> >> > >
>> >> > > > The date can be the date you cut the RC.
>> >> > > >
>> >> > > > Gary
>> >> > > >
>> >> > > > On May 10, 2013, at 16:23, William Speirs <ws...@apache.org>
>> >> wrote:
>> >> > > >
>> >> > > > > Consider this a pre release candidate for DBUTILS-2.0. I fixed
>> the
>> >> > > > > following things from RC1:
>> >> > > > >
>> >> > > > > - Removed @author tags
>> >> > > > > - Changed QueryRunner to be public
>> >> > > > > - Made ArrayHandler generic (but it's ugly because I just cast
>> to
>> >> > T[],
>> >> > > > does
>> >> > > > > anyone have a better idea here?)
>> >> > > > >
>> >> > > > > If folks (*cough* Benedikt Ritter, *cough* Emmanuel Bourg,
>> *cough*
>> >> > > Sebb)
>> >> > > > > take a look and let me know what else needs to be changed
>> before I
>> >> go
>> >> > > > > through the whole RC process, that would be greatly appreciated.
>> >> > > > >
>> >> > > > > Also, when I do cut an RC, how do I know what dates to fill in
>> for
>> >> > the
>> >> > > > > changes.xml document? I won't know when the release will happen,
>> >> and
>> >> > > I'm
>> >> > > > > not sure about the 1.6 release either. Thoughts?
>> >> > > > >
>> >> > > > > Thanks in advance...
>> >> > > > >
>> >> > > > > Bill-
>> >> > > >
>> >> > > >
>> ---------------------------------------------------------------------
>> >> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> > > > For additional commands, e-mail: dev-help@commons.apache.org
>> >> > > >
>> >> > > >
>> >> > >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> >> > Java Persistence with Hibernate, Second Edition<
>> >> > http://www.manning.com/bauer3/>
>> >> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> >> > Spring Batch in Action <http://www.manning.com/templier/>
>> >> > Blog: http://garygregory.wordpress.com
>> >> > Home: http://garygregory.com/
>> >> > Tweet! http://twitter.com/GaryGregory
>> >> >
>> >>
>> >
>> >
>> >
>> > --
>> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> > Java Persistence with Hibernate, Second Edition<
>> http://www.manning.com/bauer3/>
>> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> > Spring Batch in Action <http://www.manning.com/templier/>
>> > Blog: http://garygregory.wordpress.com
>> > Home: http://garygregory.com/
>> > Tweet! http://twitter.com/GaryGregory
>>
>> ---------------------------------------------------------------------
>> 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] Pre RC for DBUTILS-2.0
Posted by William Speirs <ws...@apache.org>.
Obviously up for debate, but are my updated thoughts:
- release 2.0 from its own branch (starting with a new changes.xml file)
- release 1.6 from trunk with the changes.xml file only including 1.x stuff
- migrate 1.x into its own branch, and 2.0 into trunk
- only release 1.x fixes if absolutely needed (this will probably never
happen as 1.4 was 2 years after 1.3, and 1.5 a year after 1.4)
Does this sound reasonable to everyone?
Bill-
On Sat, May 11, 2013 at 8:56 AM, sebb <se...@gmail.com> wrote:
> On 11 May 2013 13:21, Gary Gregory <ga...@gmail.com> wrote:
> > OK, then you need to keep 1.6 so we do not loose the history.
> >
> > 2.0 should also include all fixes from 1.6.
> >
> > Do you plan on working on 2.0 and 1.6 in parallel? If not, I'd just
> finish
> > 1.6, then do the big changes for 2.0, all from trunk.
> >
> > Otherwise, you'll need a 1.6 branch and do 2.0 in trunk, or the other way
> > around.
>
> That is the status quo: trunk is 1.6 and there is a branch for 2.0.
>
> Note that these have different Maven coordinates and different package
> names.
>
> Effectively they are two different products.
> This is fine, as 2.0 is a major rewrite.
>
> > But eventually, I think we'll want 2.0 in trunk. You'd also need to
> > port any fixes you want for 1.6 from 2.0. Unless 1.6 is a more limited
> > release that will not carry applicable fixes from 2.0.
> >
> > If it were me, I'd keep it simple and do 1.6, then 2.0, from trunk. ;)
>
> Not simple if there is any need to maintain the two incompatible versions.
>
> > Gary
> >
> >
> > On Sat, May 11, 2013 at 8:13 AM, William Speirs <ws...@apache.org>
> wrote:
> >
> >> It is and isn't up to date. There will be a 1.6 which will include big
> >> fixes. However 2.0 is a major rewrite. So I think the proper course of
> >> action is to remove the 1.6 lines from the changes file in the 2.0
> branch,
> >> but leave them in the 1.x branch (trunk). Then when I get around to
> pushing
> >> 1.6 it should all "work."
> >>
> >> Bill-
> >> On May 11, 2013 8:09 AM, "Gary Gregory" <ga...@gmail.com> wrote:
> >>
> >> > On Sat, May 11, 2013 at 7:34 AM, William Speirs <ws...@apache.org>
> >> > wrote:
> >> >
> >> > > OK, so then for the 2.0 release I'd just remove the 1.6 lines?
> >> > >
> >> >
> >> > No. Based on changes.xml, It sounds like we were going to have a 1.6,
> but
> >> > now we are calling it 2.0. So you'd change the 1.6 to 2.0.
> >> >
> >> > But... right now I see the line's description as 'Bugfixes and
> addition
> >> of
> >> > insert methods' which would not warrant a major version change.
> >> >
> >> > A major version would suggest a large change or binary
> incompatibility,
> >> > which is not noted in the changes.xml file. Is this file up to date?
> >> >
> >> > Gary
> >> >
> >> > >
> >> > > Bill-
> >> > > On May 10, 2013 5:37 PM, "Gary Gregory" <ga...@gmail.com>
> >> wrote:
> >> > >
> >> > > > The date can be the date you cut the RC.
> >> > > >
> >> > > > Gary
> >> > > >
> >> > > > On May 10, 2013, at 16:23, William Speirs <ws...@apache.org>
> >> wrote:
> >> > > >
> >> > > > > Consider this a pre release candidate for DBUTILS-2.0. I fixed
> the
> >> > > > > following things from RC1:
> >> > > > >
> >> > > > > - Removed @author tags
> >> > > > > - Changed QueryRunner to be public
> >> > > > > - Made ArrayHandler generic (but it's ugly because I just cast
> to
> >> > T[],
> >> > > > does
> >> > > > > anyone have a better idea here?)
> >> > > > >
> >> > > > > If folks (*cough* Benedikt Ritter, *cough* Emmanuel Bourg,
> *cough*
> >> > > Sebb)
> >> > > > > take a look and let me know what else needs to be changed
> before I
> >> go
> >> > > > > through the whole RC process, that would be greatly appreciated.
> >> > > > >
> >> > > > > Also, when I do cut an RC, how do I know what dates to fill in
> for
> >> > the
> >> > > > > changes.xml document? I won't know when the release will happen,
> >> and
> >> > > I'm
> >> > > > > not sure about the 1.6 release either. Thoughts?
> >> > > > >
> >> > > > > Thanks in advance...
> >> > > > >
> >> > > > > Bill-
> >> > > >
> >> > > >
> ---------------------------------------------------------------------
> >> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> > > > For additional commands, e-mail: dev-help@commons.apache.org
> >> > > >
> >> > > >
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >> > Java Persistence with Hibernate, Second Edition<
> >> > http://www.manning.com/bauer3/>
> >> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> >> > Spring Batch in Action <http://www.manning.com/templier/>
> >> > Blog: http://garygregory.wordpress.com
> >> > Home: http://garygregory.com/
> >> > Tweet! http://twitter.com/GaryGregory
> >> >
> >>
> >
> >
> >
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > Java Persistence with Hibernate, Second Edition<
> http://www.manning.com/bauer3/>
> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > Spring Batch in Action <http://www.manning.com/templier/>
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [DBUTILS] Pre RC for DBUTILS-2.0
Posted by sebb <se...@gmail.com>.
On 11 May 2013 13:21, Gary Gregory <ga...@gmail.com> wrote:
> OK, then you need to keep 1.6 so we do not loose the history.
>
> 2.0 should also include all fixes from 1.6.
>
> Do you plan on working on 2.0 and 1.6 in parallel? If not, I'd just finish
> 1.6, then do the big changes for 2.0, all from trunk.
>
> Otherwise, you'll need a 1.6 branch and do 2.0 in trunk, or the other way
> around.
That is the status quo: trunk is 1.6 and there is a branch for 2.0.
Note that these have different Maven coordinates and different package names.
Effectively they are two different products.
This is fine, as 2.0 is a major rewrite.
> But eventually, I think we'll want 2.0 in trunk. You'd also need to
> port any fixes you want for 1.6 from 2.0. Unless 1.6 is a more limited
> release that will not carry applicable fixes from 2.0.
>
> If it were me, I'd keep it simple and do 1.6, then 2.0, from trunk. ;)
Not simple if there is any need to maintain the two incompatible versions.
> Gary
>
>
> On Sat, May 11, 2013 at 8:13 AM, William Speirs <ws...@apache.org> wrote:
>
>> It is and isn't up to date. There will be a 1.6 which will include big
>> fixes. However 2.0 is a major rewrite. So I think the proper course of
>> action is to remove the 1.6 lines from the changes file in the 2.0 branch,
>> but leave them in the 1.x branch (trunk). Then when I get around to pushing
>> 1.6 it should all "work."
>>
>> Bill-
>> On May 11, 2013 8:09 AM, "Gary Gregory" <ga...@gmail.com> wrote:
>>
>> > On Sat, May 11, 2013 at 7:34 AM, William Speirs <ws...@apache.org>
>> > wrote:
>> >
>> > > OK, so then for the 2.0 release I'd just remove the 1.6 lines?
>> > >
>> >
>> > No. Based on changes.xml, It sounds like we were going to have a 1.6, but
>> > now we are calling it 2.0. So you'd change the 1.6 to 2.0.
>> >
>> > But... right now I see the line's description as 'Bugfixes and addition
>> of
>> > insert methods' which would not warrant a major version change.
>> >
>> > A major version would suggest a large change or binary incompatibility,
>> > which is not noted in the changes.xml file. Is this file up to date?
>> >
>> > Gary
>> >
>> > >
>> > > Bill-
>> > > On May 10, 2013 5:37 PM, "Gary Gregory" <ga...@gmail.com>
>> wrote:
>> > >
>> > > > The date can be the date you cut the RC.
>> > > >
>> > > > Gary
>> > > >
>> > > > On May 10, 2013, at 16:23, William Speirs <ws...@apache.org>
>> wrote:
>> > > >
>> > > > > Consider this a pre release candidate for DBUTILS-2.0. I fixed the
>> > > > > following things from RC1:
>> > > > >
>> > > > > - Removed @author tags
>> > > > > - Changed QueryRunner to be public
>> > > > > - Made ArrayHandler generic (but it's ugly because I just cast to
>> > T[],
>> > > > does
>> > > > > anyone have a better idea here?)
>> > > > >
>> > > > > If folks (*cough* Benedikt Ritter, *cough* Emmanuel Bourg, *cough*
>> > > Sebb)
>> > > > > take a look and let me know what else needs to be changed before I
>> go
>> > > > > through the whole RC process, that would be greatly appreciated.
>> > > > >
>> > > > > Also, when I do cut an RC, how do I know what dates to fill in for
>> > the
>> > > > > changes.xml document? I won't know when the release will happen,
>> and
>> > > I'm
>> > > > > not sure about the 1.6 release either. Thoughts?
>> > > > >
>> > > > > Thanks in advance...
>> > > > >
>> > > > > Bill-
>> > > >
>> > > > ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > > > For additional commands, e-mail: dev-help@commons.apache.org
>> > > >
>> > > >
>> > >
>> >
>> >
>> >
>> > --
>> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> > Java Persistence with Hibernate, Second Edition<
>> > http://www.manning.com/bauer3/>
>> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> > Spring Batch in Action <http://www.manning.com/templier/>
>> > Blog: http://garygregory.wordpress.com
>> > Home: http://garygregory.com/
>> > Tweet! http://twitter.com/GaryGregory
>> >
>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBUTILS] Pre RC for DBUTILS-2.0
Posted by Gary Gregory <ga...@gmail.com>.
OK, then you need to keep 1.6 so we do not loose the history.
2.0 should also include all fixes from 1.6.
Do you plan on working on 2.0 and 1.6 in parallel? If not, I'd just finish
1.6, then do the big changes for 2.0, all from trunk.
Otherwise, you'll need a 1.6 branch and do 2.0 in trunk, or the other way
around. But eventually, I think we'll want 2.0 in trunk. You'd also need to
port any fixes you want for 1.6 from 2.0. Unless 1.6 is a more limited
release that will not carry applicable fixes from 2.0.
If it were me, I'd keep it simple and do 1.6, then 2.0, from trunk. ;)
Gary
On Sat, May 11, 2013 at 8:13 AM, William Speirs <ws...@apache.org> wrote:
> It is and isn't up to date. There will be a 1.6 which will include big
> fixes. However 2.0 is a major rewrite. So I think the proper course of
> action is to remove the 1.6 lines from the changes file in the 2.0 branch,
> but leave them in the 1.x branch (trunk). Then when I get around to pushing
> 1.6 it should all "work."
>
> Bill-
> On May 11, 2013 8:09 AM, "Gary Gregory" <ga...@gmail.com> wrote:
>
> > On Sat, May 11, 2013 at 7:34 AM, William Speirs <ws...@apache.org>
> > wrote:
> >
> > > OK, so then for the 2.0 release I'd just remove the 1.6 lines?
> > >
> >
> > No. Based on changes.xml, It sounds like we were going to have a 1.6, but
> > now we are calling it 2.0. So you'd change the 1.6 to 2.0.
> >
> > But... right now I see the line's description as 'Bugfixes and addition
> of
> > insert methods' which would not warrant a major version change.
> >
> > A major version would suggest a large change or binary incompatibility,
> > which is not noted in the changes.xml file. Is this file up to date?
> >
> > Gary
> >
> > >
> > > Bill-
> > > On May 10, 2013 5:37 PM, "Gary Gregory" <ga...@gmail.com>
> wrote:
> > >
> > > > The date can be the date you cut the RC.
> > > >
> > > > Gary
> > > >
> > > > On May 10, 2013, at 16:23, William Speirs <ws...@apache.org>
> wrote:
> > > >
> > > > > Consider this a pre release candidate for DBUTILS-2.0. I fixed the
> > > > > following things from RC1:
> > > > >
> > > > > - Removed @author tags
> > > > > - Changed QueryRunner to be public
> > > > > - Made ArrayHandler generic (but it's ugly because I just cast to
> > T[],
> > > > does
> > > > > anyone have a better idea here?)
> > > > >
> > > > > If folks (*cough* Benedikt Ritter, *cough* Emmanuel Bourg, *cough*
> > > Sebb)
> > > > > take a look and let me know what else needs to be changed before I
> go
> > > > > through the whole RC process, that would be greatly appreciated.
> > > > >
> > > > > Also, when I do cut an RC, how do I know what dates to fill in for
> > the
> > > > > changes.xml document? I won't know when the release will happen,
> and
> > > I'm
> > > > > not sure about the 1.6 release either. Thoughts?
> > > > >
> > > > > Thanks in advance...
> > > > >
> > > > > Bill-
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > Java Persistence with Hibernate, Second Edition<
> > http://www.manning.com/bauer3/>
> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > Spring Batch in Action <http://www.manning.com/templier/>
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
> >
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [DBUTILS] Pre RC for DBUTILS-2.0
Posted by William Speirs <ws...@apache.org>.
It is and isn't up to date. There will be a 1.6 which will include big
fixes. However 2.0 is a major rewrite. So I think the proper course of
action is to remove the 1.6 lines from the changes file in the 2.0 branch,
but leave them in the 1.x branch (trunk). Then when I get around to pushing
1.6 it should all "work."
Bill-
On May 11, 2013 8:09 AM, "Gary Gregory" <ga...@gmail.com> wrote:
> On Sat, May 11, 2013 at 7:34 AM, William Speirs <ws...@apache.org>
> wrote:
>
> > OK, so then for the 2.0 release I'd just remove the 1.6 lines?
> >
>
> No. Based on changes.xml, It sounds like we were going to have a 1.6, but
> now we are calling it 2.0. So you'd change the 1.6 to 2.0.
>
> But... right now I see the line's description as 'Bugfixes and addition of
> insert methods' which would not warrant a major version change.
>
> A major version would suggest a large change or binary incompatibility,
> which is not noted in the changes.xml file. Is this file up to date?
>
> Gary
>
> >
> > Bill-
> > On May 10, 2013 5:37 PM, "Gary Gregory" <ga...@gmail.com> wrote:
> >
> > > The date can be the date you cut the RC.
> > >
> > > Gary
> > >
> > > On May 10, 2013, at 16:23, William Speirs <ws...@apache.org> wrote:
> > >
> > > > Consider this a pre release candidate for DBUTILS-2.0. I fixed the
> > > > following things from RC1:
> > > >
> > > > - Removed @author tags
> > > > - Changed QueryRunner to be public
> > > > - Made ArrayHandler generic (but it's ugly because I just cast to
> T[],
> > > does
> > > > anyone have a better idea here?)
> > > >
> > > > If folks (*cough* Benedikt Ritter, *cough* Emmanuel Bourg, *cough*
> > Sebb)
> > > > take a look and let me know what else needs to be changed before I go
> > > > through the whole RC process, that would be greatly appreciated.
> > > >
> > > > Also, when I do cut an RC, how do I know what dates to fill in for
> the
> > > > changes.xml document? I won't know when the release will happen, and
> > I'm
> > > > not sure about the 1.6 release either. Thoughts?
> > > >
> > > > Thanks in advance...
> > > >
> > > > Bill-
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<
> http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
Re: [DBUTILS] Pre RC for DBUTILS-2.0
Posted by Gary Gregory <ga...@gmail.com>.
On Sat, May 11, 2013 at 7:34 AM, William Speirs <ws...@apache.org> wrote:
> OK, so then for the 2.0 release I'd just remove the 1.6 lines?
>
No. Based on changes.xml, It sounds like we were going to have a 1.6, but
now we are calling it 2.0. So you'd change the 1.6 to 2.0.
But... right now I see the line's description as 'Bugfixes and addition of
insert methods' which would not warrant a major version change.
A major version would suggest a large change or binary incompatibility,
which is not noted in the changes.xml file. Is this file up to date?
Gary
>
> Bill-
> On May 10, 2013 5:37 PM, "Gary Gregory" <ga...@gmail.com> wrote:
>
> > The date can be the date you cut the RC.
> >
> > Gary
> >
> > On May 10, 2013, at 16:23, William Speirs <ws...@apache.org> wrote:
> >
> > > Consider this a pre release candidate for DBUTILS-2.0. I fixed the
> > > following things from RC1:
> > >
> > > - Removed @author tags
> > > - Changed QueryRunner to be public
> > > - Made ArrayHandler generic (but it's ugly because I just cast to T[],
> > does
> > > anyone have a better idea here?)
> > >
> > > If folks (*cough* Benedikt Ritter, *cough* Emmanuel Bourg, *cough*
> Sebb)
> > > take a look and let me know what else needs to be changed before I go
> > > through the whole RC process, that would be greatly appreciated.
> > >
> > > Also, when I do cut an RC, how do I know what dates to fill in for the
> > > changes.xml document? I won't know when the release will happen, and
> I'm
> > > not sure about the 1.6 release either. Thoughts?
> > >
> > > Thanks in advance...
> > >
> > > Bill-
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [DBUTILS] Pre RC for DBUTILS-2.0
Posted by William Speirs <ws...@apache.org>.
OK, so then for the 2.0 release I'd just remove the 1.6 lines?
Bill-
On May 10, 2013 5:37 PM, "Gary Gregory" <ga...@gmail.com> wrote:
> The date can be the date you cut the RC.
>
> Gary
>
> On May 10, 2013, at 16:23, William Speirs <ws...@apache.org> wrote:
>
> > Consider this a pre release candidate for DBUTILS-2.0. I fixed the
> > following things from RC1:
> >
> > - Removed @author tags
> > - Changed QueryRunner to be public
> > - Made ArrayHandler generic (but it's ugly because I just cast to T[],
> does
> > anyone have a better idea here?)
> >
> > If folks (*cough* Benedikt Ritter, *cough* Emmanuel Bourg, *cough* Sebb)
> > take a look and let me know what else needs to be changed before I go
> > through the whole RC process, that would be greatly appreciated.
> >
> > Also, when I do cut an RC, how do I know what dates to fill in for the
> > changes.xml document? I won't know when the release will happen, and I'm
> > not sure about the 1.6 release either. Thoughts?
> >
> > Thanks in advance...
> >
> > Bill-
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [DBUTILS] Pre RC for DBUTILS-2.0
Posted by Gary Gregory <ga...@gmail.com>.
The date can be the date you cut the RC.
Gary
On May 10, 2013, at 16:23, William Speirs <ws...@apache.org> wrote:
> Consider this a pre release candidate for DBUTILS-2.0. I fixed the
> following things from RC1:
>
> - Removed @author tags
> - Changed QueryRunner to be public
> - Made ArrayHandler generic (but it's ugly because I just cast to T[], does
> anyone have a better idea here?)
>
> If folks (*cough* Benedikt Ritter, *cough* Emmanuel Bourg, *cough* Sebb)
> take a look and let me know what else needs to be changed before I go
> through the whole RC process, that would be greatly appreciated.
>
> Also, when I do cut an RC, how do I know what dates to fill in for the
> changes.xml document? I won't know when the release will happen, and I'm
> not sure about the 1.6 release either. Thoughts?
>
> Thanks in advance...
>
> Bill-
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org