<div dir="ltr">On the last point, yes, perfect reasoning, however, the process of making it stable was to be able to bring it into master which had all the other changes people also wanted. :)</div><div class="gmail_extra">
<br><br><div class="gmail_quote">On 16 July 2013 21:53, Douglas Campos <span dir="ltr"><<a href="mailto:qmx@qmx.me" target="_blank">qmx@qmx.me</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Tue, Jul 16, 2013 at 04:30:02PM -0400, DM Smith wrote:<br>
> I've tagged JSword v2.0. This is the commit for the av11n work that<br>
> Martin used for And Bible.<br>
</div>yay!<br>
<div class="im">><br>
> From this point, we'll do bug fixes, tagging them as v2.0.1, v2.0.2,<br>
> ...<br>
><br>
> I'm a bit new to git, so I'd like recommendation on how to proceed. Do<br>
> we want to make a v2.0 release branch and have master be the<br>
> development toward the next release? Or do we want to do new<br>
> development on feature branches and have master be the bug fix branch?<br>
</div>master == future<br>
<div class="im">><br>
> Obviously, if we have a release branch, we'll need to put fixes on<br>
> both the release branch and on master. This will be easy at first, but<br>
> later divergent changes will cause problems.<br>
</div>unavoidable, imo - of course there will be a deprecation point I suppose<br>
<div class="im">><br>
> I'm inclined to have a release branch staying at Java 5 and have<br>
> master be Java 6. Until we have a change that should be part of the<br>
> next release and not be a fix to the current release, we can do the<br>
> work on master. (I've done just that with Martin's PR). But I can be<br>
> easily swayed.<br>
</div>maybe calling that branch "stable"<br>
<div class="im"><br>
> Also, I think de-stabilizing changes should be done on feature<br>
> branches. To me a de-stabilizing change is one that might change in<br>
> its API or may be broken from one day to the next. Much of av11n work<br>
> was de-stabilizing. By doing it on master, it compromised the ability<br>
> to have bug fixes or a release based on such. Chris B has a PR that<br>
> might be such a feature (versification mapping).<br>
</div>That's perfect reasoning in git lands :)<br>
<div class="im HOEnZb"><br>
><br>
> In Him,<br>
> DM<br>
<br>
<br>
<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>
<br>
</div><span class="HOEnZb"><font color="#888888">--<br>
qmx<br>
</font></span><div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br></div>