We could have version branches, the reason I haven't been merging to
master is that it takes work and I'm breaking things a lot now.
Ideally once we reach the stage of a release, we'll release a bunch of
sync'ed tarballs for people who want to build.
My priority (as upstream developer) is lack of friction for working,
more bureaucracy = more overhead and less work. That means I usually put
off these things more than I should rather than constantly merging my
work downstream and doing iterative testing (I'm not saying that proudly).
I'm in favour of making a hard break and hard deprecating all old
products with the new releases of our software distribution.
On 11/07/2014 04:34 AM, Eric Voskuil wrote:
> *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…
