On 11 May 2013 15:09, William Speirs <wspe...@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 <seb...@gmail.com> wrote: > >> On 11 May 2013 13:21, Gary Gregory <garydgreg...@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 <wspe...@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" <garydgreg...@gmail.com> wrote: >> >> >> >> > On Sat, May 11, 2013 at 7:34 AM, William Speirs <wspe...@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" <garydgreg...@gmail.com> >> >> wrote: >> >> > > >> >> > > > The date can be the date you cut the RC. >> >> > > > >> >> > > > Gary >> >> > > > >> >> > > > On May 10, 2013, at 16:23, William Speirs <wspe...@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-unsubscr...@commons.apache.org >> >> > > > For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > >> >> > > > >> >> > > >> >> > >> >> > >> >> > >> >> > -- >> >> > E-Mail: garydgreg...@gmail.com | ggreg...@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: garydgreg...@gmail.com | ggreg...@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-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
