Development Phases

[shannona]

I'm helping Christopher to define what we mean by various development phases. This is a first cut, and comments would be appreciated especially from @wolfmcnally @Fonta1n3 and @gorazdko.

Development Phases

The following is an overview of development phases for protocols and products at Blockchain Commons

Research

Items in the "Research" phase are still being considered and iterated. They represent thought experiments and protocols that we hope to eventually offer to the commons for development. They could include proofs of concept or napkin sketches. They are nowhere near ready for commercial development, only experimentation.

These items primarily exist as Blockchain Commons Research ("BCR") papers in our Research repo. Those all feature semantic numbering, and any BCR with a number of less than 1.0 should be considered particularly immature, with the likelihood they will be notably changed. Even BCRs with a full 1.0 release should be considered unsettled into they have been upgraded to a Wallet Improvement Proposal ("WIP"). We often will do a full refactor at that point.

Some applications, libraries, data formats, and demos may also be marked as "Research", in which case they should similarly be considered inappropriate for commercial work.

Release-Path

Once a concept has proven its fundamentals, and we have identified a path for its release (be it an application, a standard, a BIP, or something else) it is placed on the release path. This includes our WIPs and most of our repos.

Each WIP or repo should be identified with its level of stability.

Alpha. We are seeking interest and alignment with others, defining additional requirements, and exploring requirements for feature-completeness. There is still no guarantee of backward compatibility. We prefer to have at least two companies interested in implemented a protocol before advancing it from Research to Alpha Release-Path.

Late Alpha. By the time a concept reaches late alpha, we have had some success with the idea, but it is still not feature complete. By this time, we are trying to limit backward incompatibilities, but they may still occur.

Beta. At this stage, we hope to stabilize the protocols and data formats to maintain compatibility, though there could still be surprises if we discover security issues. We may still be adding features. Security reviews may be in process at this point, or they may not yet have occurred. We prefer to have at least two companies who have implemented an idea before advancing it from Late Alpha to Beta.

Feature-Complete. A product has reached its full feature set and is by now definitely undergoing security reviews if it has not already.

Final. A product's security reviews are complete, and it should be considered entirely ready for usage. In addition, at least two companies must have shipped a product, to have proven any protocols or libraries.

Repos will primarily be identified by these development phases; WIPs will additionally be identified by semantic numbering, with numbers of less than 1.0 being at best alpha.

[gorazdko]

This is very well written.

nit: interested in implementeding

[Rspigler]

I found this very helpful - I was confused around this very process. Especially re: the research stages->WIP->submitted standard

[ChristopherA]

There are now four documents on our our release best practices here:

• Best Practice Stands for Release Path
• Release Best Practices
• Development Phases
• Repo Creation Conventions

We welcome the continued addition of other secure software development best practices, iteration or refactoring of these documents, or issues that should be resolved, or discussions about how to do better.

[wolfmcnally]

I think that semantic versioning is useful for developers but less useful for user-facing apps. The problem primarily arises in when to increment the most significant component: in semantic versioning this means breaking compatibility with previous versions of the software. For a library, this usually means that projects that depend on it will need to change their source code to adopt the new major version. But for user facing apps, while this may indicate a large change in look or major new features, it rarely signifies a lack of backward compatibility. Users should never hesitate to adopt ExampleApp 2.0 when it comes out because it might be incompatible with ExampleApp 1.7. But developers using libexample 1.7 often do hesitate to adopt libexample 2.0 unless they know they are ready to update their code (sometimes significantly) because incrementing the major digit indicates the breaking of backward compatibility.

I think that Blockchain Commons needs to distinguish between these two different version number schemes and choose when to use them based on the intended target audience of the software: developers or end users.