Hi All,
I have now added my second stage boot loader to Sourceforge, which has actually brought up what to call a certain 'stage' of the project. I just wondered if there are any hard and fast rules, or I just decide what a goal is for getting to e.g. Beta. At present, I am thinking:
* Pre-Alpha - Code is a 'working unit' but does not achieve the primary goal of the project.
* Alpha - All code to achieve the main goals are present, but functionality still needs to be added (for my second stage boot loader, this is e.g. ELF binary support).
* Beta - All functionality present, just bug fixing? (not sure about this one).
* Production/Stable - a release I would be hapy to recommend to my friends!
* Mature - a replacement product has reached Beta stage.
* Inactive - recommended to use the next version, which has reached 'Stable' phase.
I'd be interested in any thoughts.
Cheers,
Adam
Setting the Project Stage
My experience and recommendation:
Pre-Alpha - packeted snapshot of your development work. Might or might not function as advertised. New versions might appear and interfaces might change any day, old packages will not receive maintenance.
Alpha - functional, can be utilized by fellow in-project developers. Old packages don't receive maintenance, but you try to keep the number of Alpha releases down and the interfaces stable so you don't upset your co-developers, but it might turn out to be inevitable.
Beta - passed peer review / alpha phase, but might yet contain bugs. In a closed project, Beta marks the stage when code goes to internal QA. In a public project, it goes into the (in)famous "public beta" at this point. The interface should be stable between first beta and release, unless major bugs are found. Beta releases should be rare, because real beta testing is arduous work, and you don't want to annoy your testers. If you take too long to follow a beta up with a release, you should think about applying maintenance fixes to your beta.
Release - beta-tested, found to be reasonably free of bugs, ready for everyday use. Will be maintained for a reasonable amount of time even after the next release is being made.
Mature - ran out of things to do for this release branch, all things left on the TODO-list would require major rewrites. Should be maintained well into the life-cycle of the next major release.
Pre-Alpha - packeted snapshot of your development work. Might or might not function as advertised. New versions might appear and interfaces might change any day, old packages will not receive maintenance.
Alpha - functional, can be utilized by fellow in-project developers. Old packages don't receive maintenance, but you try to keep the number of Alpha releases down and the interfaces stable so you don't upset your co-developers, but it might turn out to be inevitable.
Beta - passed peer review / alpha phase, but might yet contain bugs. In a closed project, Beta marks the stage when code goes to internal QA. In a public project, it goes into the (in)famous "public beta" at this point. The interface should be stable between first beta and release, unless major bugs are found. Beta releases should be rare, because real beta testing is arduous work, and you don't want to annoy your testers. If you take too long to follow a beta up with a release, you should think about applying maintenance fixes to your beta.
Release - beta-tested, found to be reasonably free of bugs, ready for everyday use. Will be maintained for a reasonable amount of time even after the next release is being made.
Mature - ran out of things to do for this release branch, all things left on the TODO-list would require major rewrites. Should be maintained well into the life-cycle of the next major release.
Every good solution is obvious once you've found it.