Proper Versioning Scheme
As a follow-up to my other topic, this nicely joins with that.
Sorry for the length and rambling, I'm trying to get my ideas out. If this meets with positive signs, I'd be happy to formulate a proper policy document.
A big problem with ispCP is that bugfixes and new features are joined in the same release. This can cause a large problem for hosting providers, and even individuals using the software for their own servers. Often, all a provider will want is the bugfixes. Sometimes, the new features are either unwanted or cause problems (as in the change in minimum software versions between 1.0.6 and 1.0.7).
A proper release and version strategy goes a long way toward cleaning up these problems.
Before I start with my idea, some background. My profession is a system administrator. I work for a small company that develops websites for other businesses. By title, I am in charge of keeping both our internal servers and the servers of our customers in working, secure, order. As we are a small company, I am often an architect. In this role, I develop development and deployment strategies for the products we write. In some cases, we are responsible for multi-year management and feature development for the software we've written for our customers. Some customers are a bit loose on procedure, others are very formalized. As a result, I've got a good handle on what should and should not be done when managing software. I also see where productivity can take a hit when things aren't managed correctly.
I know one of the previous development solutions was to keep a branch for each new feature and juggle integrations and so on. I'm not sure if that's still going on (I hope not), so I'll start from the ground up. My ideas are from the Subversion view, which I believe is still being used for a VCS on this product.
My normal preference is to keep mainstream development on trunk. For developing new features on complex products and maintaining stable releases, it seems to work best. As ispCP is currently still very tightly-coupled, new features have to be developed together (a new theme design affects all areas, for example). For maintenance, you use branches. You can also use branches for long-term feature additions where a single development cycle is too short. Tags are used to mark each release.
So, my ideal layout would be something like this:
/
/trunk - Development
/branches
/branches/1.0 - Stable branch 1.0.x
/branches/1.1 - Stable branch 1.1.x
/branches/1.2 - Stable branch 1.2.x
/tags
/tags/release-1.0.0 - Release 1.0.0
/tags/release-1.0.1
/tags/release-1.0.2
/tags/release-1.1.0
/tags/release-1.1.1
/tags/release-1.1.2
Branches and tags are "free" in Subversion, so organizing is very nice and quick.
So, how does this apply to ispCP versioning?
Well, it will allow the separation of features and bugfixes. Even better, it'll make things work better in development and provide a reliable platform for end-users.
Each branch is a "stable" platform to develop for. Each branch should be feature-frozen (in other words, no new features added). This enforces discipline and prevents last-minute bugs from creeping in.
Since you have just a small development team, I suggest only keeping two branches open. For instance, when you release 1.2.0, all 1.0.0 releases would be discontinued, if possible.
Why two branches? Well, to avoid having a supported platform be dropped by a new release. For example, a supported platform (CentOS/RHEL 5, perhaps) could still run on 1.6.x even if 1.7.0 introduced requirements on versions that are not possible on that platform. This will reduce support burden when bugs show up and the user can't upgrade because they can't meet a dependency.
Further, overall, not much code in ispCP changes between releases. Many things still work the same way. If a bug is reported for 1.6.5, you can guess that it's probably in 1.7.2 (unless that section has been rewritten). As you fix bugs in the old stable release branch, you make a stronger base for the new features in development. As a bonus, you can also easily test if a bug was due to a new feature, allowing easier handling of problematic new code. Jumbling fixes and new features creates an ever-changing base that's not solid.
The release phase:
Like in most software, a version will go through beta and release candidate stages before release. By treating these as formal stages and exercising discipline, you can provide a stronger product on release with fewer issue reports. For example, changing required software versions in an RC phase would be forbidden except in very special circumstances. Likewise, trying to add substantial new features during a beta would also be forbidden except in very special circumstances.
Let's review the stages and what they should be used for.
Beta
The product at this phase should have the majority of new functionality completed. The basis of the product should be in good shape at this stage. Focus should be on completing functionality, trimming features that cannot be finished in a reasonable time, and fixing major bugs.
Release Candidate
This stage is exactly as the name says. All functionality should be complete. Incomplete functionality should not exist and have been removed. All blocking and major bugs should be closed before entering this phase. Only bug fixes should be applied. As the name states, each RC should be the candidate to mark as the final release.
Note that at neither point is is okay to add a new feature. Also note that the feature set should be fully defined before even entering the beta phase.
Offering a more formalized and dependable release system can grow the community, improve development, and even grow the developer pool.
Please consider this information/suggestion/proposal. If you like the idea, I'd be happy to organize things a bit better and develop a few documents for development procedures (if you promise to at least try them for a release or two!).
|
Search
Member List
Calendar
Help
