[jsword-devel] JSword 2.0 tagged

[Chris Burrell]

*Some thoughts:*

   - 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)
   - We can create a branch for 2.0 when we first need to commit a fix
   - In terms of process, I'd suggest we always want to develop on feature
   branches, but they get merged into master when ready.
   - Choosing to build off master can be associated with the risk of it
   being unstable.
   - A developer can always choose to build off a different branch/tag if
   he wants stablity
   - 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.
   - I'd prefer to go for small incremental changes and therefore accepting
   smaller PRs into master rather than big sweeping changes.


*In terms of my changes:*

   - I can't immediately see more bits of JSword I *need *to change for
   STEP at the moment
   - There are lots of unit tests and they test all the different
   combinations allowed in a file
   - 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
   - I am hoping to get some German mappings soon. (not blocking - would
   prefer a small change later dissociated from the current dev work)
   - I would also like Martin to test the initialising performance hit vs
   his version.
   - 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).



Chris









On 16 July 2013 21:30, DM Smith <dmsmith at crosswire.org> wrote:

> I've tagged JSword v2.0. This is the commit for the av11n work that Martin
> used for And Bible.
>
> From this point, we'll do bug fixes, tagging them as v2.0.1, v2.0.2, ...
>
> 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?
>
> 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.
>
> 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.
>
> 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).
>
> In Him,
>         DM
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/jsword-devel/attachments/20130716/41b0fde0/attachment.html>