Makes sense :)
What about using git-submodules
2014-11-06 23:34 GMT-05:00 Eric Voskuil <eric@???>:
> *TL;DR*
>
>
>
> · master & develop isn’t working
>
> · version1, version2,… branches are in place
>
> · we would like to delete master & develop quickly
>
> · libbitcoin-node is a new repo
>
> · there is a rational roadmap unfolding
>
>
>
> A problem we have is that the git flow
> <http://nvie.com/posts/a-successful-git-branching-model> model does not
> envision support for down-level releases. It's ideally suited for a web
> service, where the product owner only maintains a single "release". This
> isn't practical for products that maintain concurrent releases, because
> inevitably those releases require independent updates, documentation, etc.
> In my experience this is alays a problem with software that "ships" (vs.
> that which you build privately and run as a service).
>
>
>
> Presently we have a release on *obelisk/master *and of *sx/master*. These
> have essentially frozen *libbitcoin/master* as a release, so as not to
> break these products. This is why we have hardly pushed anything to master
> since creating the develop branches.
>
>
>
> Develop is operating as a next version branch. So presently we have
> *obelisk/develop*, *libbitcoin/develop*, and *libbitcoin-blockchain/master
> *(where there is no develop) working toward a new Obelisk (v2) release.
> In this case the branch conventions don't make sense unless we plan to kill
> obelisk and sx immediately upon release of v2 (which is not a good idea).
> As such we have a problem.
>
>
>
> This started to surface yesterday on IRC, as changes in
> *libbitcoin/develop* that are supporting changes to
> *libbitcoin-blockchain* started to affect the pending release of
> *bx/master*. *bx* depends on *libbitcoin-client/master* which in turn
> depends on *libbitcoin-protocol/master*, as well as *libbitcoin/develop*.
> Because of changes to *libbitcoin-develop*, *libbitcoin-client* and *bx*
> were broken. This is because *libbitcoin-client* provides backward compat
> for *obelisk/master* via API types exposed via *libbitcoin/develop*. So
> we pulled the API types out of *libbitcoin/develop* and moved them into
> *libbitcoin-client*. Ideally these should exist in an independent
> interface repo (like *libbitcoin-protocol*) but that isolation didn’t
> previously exist, and *libbitcoin-protocol* shouldn’t take on the obelisk
> interface.
>
>
>
> As you can see, this can get really bad and without action is going to get
> much worse. With parallel development on interdependent products, some with
> more than one supported release version, we cannot simply rely on master
> and develop. Different components need to take dependencies at different
> levels as thngs evolve. Once an API ships it cannot remain in flux. Imagine
> Boost continuing to change the API, there would be no versions and it would
> be unusable.
>
>
>
> So to quickly isolate these issues, allowing work to continue, we have
> instituted release branches. The idea is simple, each release for a given
> repo on its own branch. What constitutes a “released” branch (i.e.
> quality/stability level) is a matter of documentation for that branch.
> Certainly obelisk/master, sx/master and libbitcoin/master are “released”.
> The branch distinction is considered a “major” version break. Breaking
> changes to the API generally fall into this category. This resolves the
> issue of supporting downlevel versions with updates and documentation, and
> also resolves the ambiguity arising from treating master and develop as two
> distinct versions.
>
>
>
> However it also implies that master need to go away entirely. I have
> removed master and develop from *libbitcoin-protocol*, *libbitcoin-client,
> libbitcoin-node* and *bx*. So as not to break any current work, I have
> not removed these branches yet in other repos (obelisk, sx, libbitcoin,
> libbitcoin-blockchain), but have set the most recent version branch as the
> default in all cases. But master and develop should be deleted quickly, so
> as to prevent confusion. Also package version numbers have been update to
> correlate to the version branches.
>
>
>
> The only exception is current work ongoing in libbitcoin/develop. This
> branch (only) has unique recent work that was not ported to the release
> (v2) branch. Work is underway to complete libbitcoin-node and have obelisk
> (v2) take dependency on it, as well as libbitcoin (v2) and then to purge
> libbitcoin/develop. In other words we are trying to prevent a v3 branch of
> libbitcoin before v2 even ships!
>
>
>
> This is everything starting from where we are, to where we will be very
> shortly (*BX *and* DarkWallet*) and the thinking for *libbitcoin-server. *Basically
> we are in the process of shipping version2 products and starting on
> version3, while still supporting version1.
>
>
>
>
>
> *Utility*
>
> · libbitcoin/version1
>
> o Boost
>
> o GMP
>
> o Secpk256k1
>
> o LevelDB (conditional)
>
> o OpenSSL (test only)
>
> · libbitcoin/version2
>
> o Boost
>
> o GMP
>
> o Secpk256k1
>
>
>
> *Obelisk*
>
>
>
> · obelisk/version1
>
> o libbitcoin/version1
>
> o libconfig++
>
> o Sodium
>
> o ZMQ
>
> o CZMQ
>
> o CZMQPP
>
>
>
> *SX (spesmilo)*
>
>
>
> · sx/master (version1)
>
> o libbitcoin/version1
>
> o libwallet/master (version1)
>
> o obelisk/version1
>
> o libconfig++
>
> o ncurses
>
> o python, etc…
>
>
>
> *DarkWallet Obelisk*
>
>
>
> · libbitcoin-blockchain/version2
>
> o libbitcoin/version2
>
> · libbitcoin-node/version2
>
> o libbitcoin-blockchain/version2
>
> · obelisk/version2 (DarkWallet release)
>
> o libbitcoin-node/version2
>
> o libconfig++
>
> o Sodium
>
> o ZMQ
>
> o CZMQ
>
> o CZMQPP
>
> *BX*
>
>
>
> · libbitcoin-protocol/version2
>
> o libbitcoin/version2
>
> o protobuf
>
> · libbitcoin-client/version2
>
> o libbitcoin-protocol/version2
>
> o Sodium
>
> o ZMQ
>
> o CZMQ
>
> o CZMQPP
>
> · libbitcoin-explorer/version2 (bx)
>
> o libbitcoin-client/version2
>
>
>
> *Libbitcoin Server (*) & Libbitcoin Node (**)*
>
>
>
> · libbitcoin-blockchain/version3
>
> o libbitcoin/version2 (or 3 as necessary)
>
> · libbitcoin-node/version3
>
> o libbitcoin-blockchain/version3
>
> · libbitcoin-server/version3
>
> o libbitcoin-blockchain/version3
>
> o libbitcoin-protocol/version2 (or 3 as necessary)
>
> o Sodium
>
> o ZMQ
>
> o CZMQ
>
> o CZMQPP
>
>
>
> * libbitcoin-server/version3 may also include layered websockets/JSON
> protocol support.
>
> ** libbitcoin-node/version3 should be able to install independently
> alongside libbitcoin-server/version3.
>
>
>
> e
>
> _______________________________________________
> Libbitcoin mailing list
> Libbitcoin@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin
>
>
::
Re: [Libbitcoin] git flow, versioni…
