<div dir="ltr"><div><i>Some thoughts:</i></div><ul><li>I'd agree with master remaining the going forward & development branch. I think other GitHub projects tend to follow the same pattern (e.g. JBoss)<br></li><li>
We can create a branch for 2.0 when we first need to commit a fix<br></li><li>In terms of process, I'd suggest we always want to develop on feature branches, but they get merged into master when ready.<br></li><li>Choosing to build off master can be associated with the risk of it being unstable. <br>
</li><li>A developer can always choose to build off a different branch/tag if he wants stablity<br></li><li>We shouldn't merge a change in until we're confident it works, but we should try master as up-to-date as possible. When branches diverge a lot this creates issues.<br>
</li><li>I'd prefer to go for small incremental changes and therefore accepting smaller PRs into master rather than big sweeping changes.</li></ul><div><br></div><div><i>In terms of my changes:</i></div><div><ul><li>I can't immediately see more bits of JSword I <b>need </b>to change for STEP at the moment <br>
</li><li>There are lots of unit tests and they test all the different combinations allowed in a file<br></li><li>STEP uses this new functionality for almost every passage lookup, key validation, etc. and I've tested numerous different passages all of which work as expected in STEP<br>
</li><li>I am hoping to get some German mappings soon. (not blocking - would prefer a small change later dissociated from the current dev work)<br></li><li>I would also like Martin to test the initialising performance hit vs his version.<br>
</li><li>I think we need to think further into how we integrate the Versification Mappers into the core code (that's for a different thread). This would simplify some of the frontends' code. (things like adding keys together could work across versifications).</li>
</ul></div><div><br></div><div><br></div><div>Chris</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On 16 July 2013 21:30, DM Smith <span dir="ltr"><<a href="mailto:dmsmith@crosswire.org" target="_blank">dmsmith@crosswire.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I've tagged JSword v2.0. This is the commit for the av11n work that Martin used for And Bible.<br>
<br>
>From this point, we'll do bug fixes, tagging them as v2.0.1, v2.0.2, ...<br>
<br>
I'm a bit new to git, so I'd like recommendation on how to proceed. Do we want to make a v2.0 release branch and have master be the development toward the next release? Or do we want to do new development on feature branches and have master be the bug fix branch?<br>
<br>
Obviously, if we have a release branch, we'll need to put fixes on both the release branch and on master. This will be easy at first, but later divergent changes will cause problems.<br>
<br>
I'm inclined to have a release branch staying at Java 5 and have master be Java 6. Until we have a change that should be part of the next release and not be a fix to the current release, we can do the work on master. (I've done just that with Martin's PR). But I can be easily swayed.<br>
<br>
Also, I think de-stabilizing changes should be done on feature branches. To me a de-stabilizing change is one that might change in its API or may be broken from one day to the next. Much of av11n work was de-stabilizing. By doing it on master, it compromised the ability to have bug fixes or a release based on such. Chris B has a PR that might be such a feature (versification mapping).<br>
<br>
In Him,<br>
DM<br>_______________________________________________<br>
jsword-devel mailing list<br>
<a href="mailto:jsword-devel@crosswire.org">jsword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/jsword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/jsword-devel</a><br>
<br></blockquote></div><br></div>