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 <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 > >
