Seed 2019-06-01

By Max Woerner Chase

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:

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:

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.