[annotator-dev] Branching v2.0.x
nick at whiteink.com
Wed Oct 30 08:22:05 UTC 2013
Randall Leeds wrote:
> In the interest of moving forward toward Annotator v2 I've just
> forked the current master branch to two branches: v1.2.x and v2.0.x.
Saw this -- great, and this is absolutely what I intended to do as soon
as we pushed out 1.2.8, which I'm happy to do now, but if it's possible
to integrate your source map packaging stuff, I'd been keen to do so.
> I would like to propose that maintenance fixes only land on v1.2.x.
> We should make a release there shortly with anything that's landed
> since the last tag.
> We should aim to land Nick's WIP branch on v2.0.x.
Agreed, but this now leaves us with three branches -- master, v1.2.x and
v2.0.x. I think we only need two at any one time, and my preference
would be to fork v1.2.x immediately after releasing 1.2.8, and then
merge in the wip branch and have master become the unstable 2.0.x
Alternatively, if we're worried that people will check out master and be
confused by the potentially unstable state of the repo, then we can keep
1.2.x on master until such time as we're willing to promote a 2.0.x
branch to master, and only then fork a release branch for support of the
1.2.x series? Meanwhile, formalise the development on the v2 stuff on a
2.0.x branch as you've created.
My strong preference is for the first of these two options, as it puts
the v2 work front and center. Opinions
> Kristof Csillag will follow up over the next few weeks with e-mails
> proposing changes to v2.0.x that integrate work we've done at
> Hypothes.is which may break backward compatibility.
> In this way, we can continue to support the existing formats and
> ecosystem and make rapid changes to v2.0.x, stabilizing over time
> until we feel we can tag v2.0.0.
> I wanted a way to start landing changes upstream without worrying
> about v1.2.x compatibility. That way we don't have to land the WIP
> branch with tons of other changes and call it v2.0.0 immediately. We
> can iterate to v2.0.0 but things can be landed instead of staying on
> side branches indefinitely.
> Happy Annotating, R
Thanks for doing this and getting this stuff moving. I spent another few
hours last night cleaning up the WIP branch, and the resulting changes
in the nature of the tests (both for Annotator core and the Store
plugin) are very encouraging -- it's much more obvious that we're doing
real unit testing now, rather than some kind of spaghetti testing that
crosses every available unit boundary.
It's probably only another few hours until it's mergeable.
More information about the annotator-dev