What does version control bring to the table? Old hands at software development will tell you it's a lot; here are some of the better features, among others:
- Project-wide "undo". No matter how screwed up your copy of the code is, you're only one "Revert" command away from a working copy.
- Historical diffs. You can see how a file evolves over time, and see it at any point in its history. This ensures you never really "lose" old code, and you don't have to find anywhere to put that old code either.
- Branches and tags. The ability to branch your code means that if you have major, destructive changes you want to try to make, you can try them out without hurting the overall code-base. Tags let you mark a version of the code, so that if somebody is having trouble with their copy of "CMXpress 0.9.8," you can rewind right to it and see exactly what they have.
- Shared development. If someone else wants to contribute code or make fixes, they can do so safely — even while you're working on the code yourself! Conflicts between changes can be resolved nearly instantly, too. You can have whole teams working on various pieces of the code without any trouble.
- More transparency. It's easy for anyone with an SVN login (or anonymous SVN access) to see the code and get the latest copy of anything, even without waiting for formal releases. Anybody who wants to be right on the cutting edge can be.
I'm using Subversion (SVN) for the first three of those, and the last two are nice side benefits. We're using SVN very heavily at work as our version-control system, and I've really learned to love it.
This, then, is the revised development roadmap:
- Import CMXpress 0.9.8, 0.9.8a, 0.9.9, 0.9.9a, 0.9.10, 0.9.10a, 0.9.10b, and 0.9.10c into the subversion repository. (A todo for this week.)
- Integrate previously-unmanaged resources, like artwork, that have been sitting off to the side (and out of the releases) for a long time. (A todo for the end of this week.)
- Integrate fixes that have fallen out of testing CMXpress on Microsoft IIS. (I don't think IIS will be a formal target yet, since there's no SQL Server backend yet, but I have been able to get CMXpress to run on Windows on IIS with MySQL, and I'd like to work in some of the bug-fixes that allowed that to happen.) (A todo for this weekend, I hope.)
- Add support for managing user signatures, the only really major missing chunk of functionality in the current builds. (A todo for next week.)
- First public beta release.
Now, after the public beta release, I'm going to spend my time doing a few different things immediately:
- Several sites running CMXpress need to be upgraded to 0.9.10 (or whatever the newest version will be).
- Need to help skin Triquetra Cats.
- Need to help skin Hero In Training.
Now, I plan to get the current code-base past beta to a stable 1.0 release, but I've already started to see what could be called a v2.0 feature branch creeping up on the horizon. This would follow a lot of the same basic principles as v1.0, but some of the guts in the current all-too-ad-hoc data-access layer would be replaced with something using a generated object-relational mapping from some kind of schema; and the markup and CSS would be cleaner and better-separated; and the Javascript would be less obtrusive. This would improve compatibility considerably in many ways, simplify some parts of the design, and easily allow it to be bound to other database backends (PostgreSQL, SQL Server, plain text files...). It's sorely tempting to include a proper unit-test engine in there as well.
I don't really know when work on v2.0 will start, since I'm still busy working on v1.0, but I'm starting to think the basic structure of the soon-to-be-called v1.x, while good and usable, needs to have some of its guts replaced to help it grow to meet future needs. That won't affect most people who own sites — they'll just upgrade and everything will work — but for those of us living in the code, it'll make a big difference.
