Three Dollar Quill

I've got enough diagrams, proofs-of-concept, and notes on Seed's design that I think I'll be ready to tackle it, once I have the energy. I'll try to get on this tomorrow afternoon or so (probably by making a todo list first), but for now I'll try to lay out what I want to try to do with Seed.

The cloning model that gave Seed its name is relatively simple, but I ended up thinking, you know, while I'm thinking of workflows, why don't I see what I can come up with for the stuff that isn't cloning out new projects?

There were three basic areas I ended up trying to cover, more-or-less orthogonal, but with some dependencies:

• A workflow inspired by test-driven-development
• Branches based on possible future semver versions
• A way to have generated code be "tracked" without polluting the master or development branches.

For the semver stuff, there's a "master" branch that can produce any of the "next" possible semvers after the highest release: a major, minor, or patch version. Furthermore, there are branches for older major versions, which can produce new minor versions, and branches for older minor versions, which can produce new patch versions. My current notes don't enforce any dependencies between these forked-out branches.

For TDD, I've got the following basic ideas:

• All potentially releasable branches must only ever test green.
• There are "feature" branches which are associated with a release branch, test red, and only differ from their associated branch in test code.
• There are transient "refactor" branches that involve changes to test code or code under test, not both. They must be green to be accepted, and merge to their corresponding releasable branch.
• None of these kinds of branch should have conflicts.
• "feature" branches can be modified with changes to test code or code under test, not both at once. Test code changes that maintain red are accepted; test code changes that convert to green prompt the user for whether it should be counted as a refactor; code-under-test changes that maintain red are rejected, and changes that convert to green are accepted.
• Changes to the releasable code render other branches stale (they're missing patches). The condition has to be manually removed by a "freshen" command, which basically attempts to recreate the branch from the new releasable code, and the result is either "red" (replace), "green" (confirm merge), or "conflict" (abort freshen, prompt user to resolve manually).

For builds, I haven't quite nailed it down. There basically needs to be a branch that takes no patches and has different ignore behavior. Another possibility would be to take patches, commit build artifacts on the branch, one branch per releasable branch. In any case, the intermediate build is done from the releasable branch with the target directory in the build branch (there are a lot of clones), then the final build is done from the build branch and the artifacts propagated to the other directories.

I think all of this covers everything I'd like to do with this idea. I'll have to write up a list tomorrow, like I said, and probably draw some tables.

It's super late. Good night.