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