Propel support is not in the 2.0 branch

[jmikola]

Propel support is not in the 2.0 branch

[richardmiller-zz]

It was already branched so I guess it was just an oversight as the PR was against master.

[jmikola]

What's a safe resolution here? Mass cherry-pick? I'm pretty sure this issue came up with some FOS bundles before, but I don't recall exactly how they resolved it.

CC: @stof, @lsmith77

[willdurand]

I missed the 2.0 branch.. What's the aim of this branch ?

[jmikola]

Maintaining compatibility with Symfony's 2.0 branch (other bundles are using the same convention).

[lsmith77]

yeah .. git cherry-pick the commits (not the merge commit though)

[willdurand]

Ok that's the convention I also use.

Envoyé de mon iPhone

Le 28 déc. 2011 à 23:35, Jeremy [email protected] a écrit :

Maintaining compatibility with Symfony's 2.0 branch (other bundles are using the same convention).

---

Reply to this email directly or view it on GitHub:
https://github.com/Exercise/FOQElasticaBundle/issues/54#issuecomment-3295963

[jmikola]

@richardmiller: Here's the diff between 2.0 and master: Exercise/FOQElasticaBundle@2.0...master

We need to decide which of these can be backported - presumably by cherry-picking. Also, if you invert that diff, there are two commits that are in 2.0 but not master. Is that the result of your own cherry-picking (afaik, it creates new commit ish's).

[stof]

@jmikola a cherry-pick indeed creates new commits

[jmikola]

@stof in that case, it should be safe merging 2.0 into master again. I presume git will just ignore the duplicate commits, although I suppose they'll appear in the timeline twice.

[richardmiller-zz]

Of the two in 2.0 master and not in master, one is me cherry picking a change i made to master that should have been made to 2.0. The other is because I did that before pulling a different change to my local copy and had to merge it in. Not sure what the effects on the timeline will be but I can't see any issue with merging 2.0 back in as the changes will be the same.

[richardmiller-zz]

I think that everything by anyone but me can be cherrypicked into 2.0 and the following ones of mine can be:

69afe16 b959905 7832fbc 4bd1aa7 564f1c8 0386f8e 510d411

[richardmiller-zz]

Also what about the README should this be the same for both pointing out anything that is different in 2.0 or tailored to what is correct in each branch? The latter seems more technically correct but the former seems like it will cause less confusion when people refer to the master one on github whilst using the 2.0 branch.

[richardmiller-zz]

@jmikola I have cherry picked what I can back into 2.0 and merged it back into master. Just realised that I missed Lukas' comment about not the merge commit and I used the merge commit where it was a PR being merged in. Not sure what difference this makes. It all seems to be ok for me, the history looks odd though and they still show up as differences in the compare view.

[jmikola]

@richardmiller: Sorry for my absence, but I was traveling for the week. Regarding the merge commit, it really isn't something we'd want to cherry-pick (the actual changes are the earlier commits). But I'm not sure what the repercussions might be other than some more junk in the history.

Moving forward, what are the features that are both documented in the README and only present in the master branch? For sake of simplicity, I'd prefer to maintain one README file and a list of shortcomings for the 2.0 branch (either in the same file or a separate one linked from the authoritative README).

[richardmiller-zz]

@jmikola sorry I'd not use cherry-pick before. The only real difference at the moment is the use of the doctrine style shortcuts and annotations for the custom repositories. This is not documented yet at all anyway. I think that the use of annotations could go into 2.0 anyway. I will have a look at making this available in 2.0 as well as adding the docs for it.

[richardmiller-zz]

I have added the annotation use to 2.0 and updated the docs so I am closing this.