Hi Kasper, I agree we could take changes form master to 4.0.x branch. What I meant to say we should start branching off from 4.0.0-incubating tag and then merge changes explicitly to that branch from master. This will create commit hashes that could help us track changes from master to the branch.
Unless branching off from latest in master could also bring the 4.0.0-incubating tag to the branch. - Henry On Sun, Jan 19, 2014 at 12:04 PM, Kasper Sørensen <[email protected]> wrote: > Hmm I get what you mean, but I feel that the changes made since the tag was > made is anyways non-breaking and beneficial for a potential 4.0.1 release. > Maybe it was a bit of a "too pragmatic" (not strict / by the book) way to > do the branching, but functionally I guess it archieves the goal ... or? > > > 2014/1/19 Henry Saputra <[email protected]> > >> Thanks Kasper, and it needs to branch off the tag Ankit added for >> 4.0.0-incubating. >> >> - Henry >> >> On Sunday, January 19, 2014, Kasper Sørensen < >> [email protected]> >> wrote: >> >> > I agree we should anyways have a 4.0 branch I think ... At least if we >> want >> > to do more 4.0.x releases, so I'll go ahead and make a remote branch >> called >> > 4.0.x straight away. >> > >> > >> > 2014/1/19 Henry Saputra <[email protected] <javascript:;>> >> > >> > > I am +1 do merge now assuming Ankit create branch for preparing 4.0 >> > > instead of just tag. >> > > >> > > This will make release preparation easier and creating remote branch >> > > in git is cheap. >> > > >> > > - Henry >> > > >> > > On Fri, Jan 17, 2014 at 12:46 AM, Kasper Sørensen >> > > <[email protected] <javascript:;>> wrote: >> > > > So Henry did the review on the review board, and we now have a branch >> > > that >> > > > is pretty good for integration into the master branch. Shall I do the >> > > > merging already, or do we want to wait and verify the final go on the >> > 4.0 >> > > > release (which is still in a vote on general@ list I think)? >> > > > >> > > > >> > > > 2014/1/7 Kasper Sørensen <[email protected] >> <javascript:;> >> > > >> > > > >> > > >> And thanks to Henry for letting us know about the new review board >> we >> > > >> have... >> > > >> >> > > >> This same branch diff can be reviewed here now: >> > > >> https://reviews.apache.org/r/16680/ >> > > >> >> > > >> >> > > >> 2014/1/5 Kasper Sørensen <[email protected] >> <javascript:;> >> > > >> > > >> >> > > >>> Hi all, >> > > >>> >> > > >>> I've made a remote branch called 'spring-module' to represent the >> > > attempt >> > > >>> at fixing issue METAMODEL-11 which is about having a spring >> > FactoryBean >> > > >>> available for constructing DataContext objects based on variable >> > > factory >> > > >>> properties [1]. >> > > >>> >> > > >>> It so far works for JDBC, CSV and Excel DataContexts. Would >> > appreciate >> > > >>> any kind of review or thoughts on the approach. >> > > >>> >> > > >>> To get an idea of how it would work from a Spring POV, it will make >> > > sense >> > > >>> to take a look at the testcases. These read files from the folder >> > > >>> spring/src/test/resources/examples [2] ... >> > > >>> >> > > >>> Some questions: >> > > >>> * Could we make this more extensible somehow, so it would be >> > possible >> > > to >> > > >>> plug in other datacontext types than those we have out of the box? >> Is >> > > that >> > > >>> desirable/important? >> > > >>> * Would the current style of implementation work if some >> > dependencies >> > > >>> are missing at runtime. For instance, would it work for a CSV >> > > DataContext >> > > >>> when MetaModel-excel is not on the classpath, or does the imports >> in >> > > the >> > > >>> top of the factory bean class require ALL modules to be available >> on >> > > >>> classpath? If so, that's kinda unfortunate... >> > > >>> >> > > >>> Kind regards, >> > > >>> Kasper >> > > >>> >> > > >>> [1] https://issues.apache.org/jira/browse/METAMODEL-11 >> > > >>> [2] >> > > >>> >> > > >> > >> https://git-wip-us.apache.org/repos/asf?p=incubator-metamodel.git;a=tree;f=spring/src/test/resources/examples;h=130605d4286dd68c5b2e8acc3c2cdd2a8f0d5b6a;hb=refs/heads/spring-module >> > > >>> >> > > >> >> > > >> >> > > >> > >>
