You're right. That is the best way to do it. I am used to SVN where these kinds of things are hard, but it shouldn't be a problem in git I think. I can do it tomorrow if no one beats me to it.
2014/1/19 Henry Saputra <[email protected]> > 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 > >> > > >>> > >> > > >> > >> > > >> > >> > > > >> > > >> >
