It's no longer a question of work, it's a feasibility/quality issue.
Changes in released code that break either dependent builds or wire
protocol must be clearly isolated. Package version number increments
can't resolve these issues. Forced upgrade is survivable as long as we
aren't introducing breaks. But this is specifically what we are dealing
with.

There's really no advantage of a tarball over a branch. A branch is
easier to maintain and exposes a web presence for documentation and any
ongoing patches, issues, etc. A good example is
https://github.com/bitcoin/bitcoin, which maintains branches for each
"release". Tarballs can then be created from released branches, but
there's not much additional utility for that effort.

I'm not in favor of forcing breaking changes on the community on the
instant of their release. That is not feasible for a distributed
client-server system that takes time to deploy, integrate with, and gain
acceptance. This approach would result in the coupling of clients and
dedicated servers in order to prevent breaks, fracturing any potential
for widespread community services.

Creating a release branch is a very simple means of deprecating (vs.
obsoleting). It still allows everyone who's ready to move on to the new
branch immediately and requires almost no effort to create (and if
desired maintain) past releases. As such there's really no downside to
this approach. Notice that bitcoind is managed in this same manner:
https://github.com/bitcoin

e


On 11/07/2014 02:08 PM, Amir Taaki wrote:
> 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
>>
>
>
>
> _______________________________________________
> Libbitcoin mailing list
> Libbitcoin@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin
>