Re: I'd like to suggest a more 'stable' branch for us production weenies [message #5455 is a reply to message #5452] |
Tue, 03 September 2002 16:21 |
Ilia
Messages: 13241 Registered: January 2002
Karma:
|
Senior Member Administrator Core Developer |
|
|
You've raised a number of valid points so, allow me to explain the situation.
FUDforum has 1 development tree, once a certain milestone is reached I tag the source code at that point. If it is my opinion that the code of the forum is stable then I announce it as a stable release, otherwise it is marked as development release. In between releases, the code from the LATEST CVS should be considered unstable since it is being worked on, and quite often I commit some parts while others are still in testing/development, which results in non-working code.
The milestone, I've mentioned above, usually represents a certain stage in development such as completion of a major codee change, new major feature, a large number of bug fixes etc...
In most cases each stable release is preceded by 1 or 2 RC releases, that allow me to hammer out the few remaining bugs before the stable release. I do not release a stable release until there is a 1-2 day period during which there are no bug reports that pertain to the stable release candidate.
I have some experience with working on projects that separate development & 'stable' trees into completely seperate trunks. While it has some aesthetic elements, it results in numerous problems such as not-backported patches and similar inconsistencies. It becomes a grueling task for the release manager to handle this situation when it is time to make the 'stable' release. Therefor, I believe my time is better spent writing code and fixing bugs, rather then spending several days before each stable release back-porting fixes.
Your comments about 'Release Candidate' (RC) are very correct and I admit I somewhat misuse the term, since there are always a few changes between the last RC and the stable release. This usually occurs only if the bug fixes are very minor and I can test that the changes made have no adverse effects on the rest of the code. If any new features are added they are usually quite independent from the rest of the code and/or disabled by default. My reasoning behind this is to get those features out in the open so that people who want them can try them out and if there are any issues by the next stable release they are resolved. At the same time ensuring that those features do not cause problems for people not using those features.
Unfortunately, like with any other projects, even with the Q&A done by me and various people who try the development release there are a few bugs here in there in stable releases. Fortunately, lately those bugs have been quite minor and do not hinder the operation of the forum. I also find that thanks to the RC process the number of bugs found is stable releases tend to be quite small.
All that said, I believe it is good practice to always wait 3-4 days after any release before trying out, unless the release address' security issues or contains features that you simply 'MUST' have. Personally, I follow this practice when dealing with any software that I use be in the Linux kernel or a mail client.
FUDforum Core Developer
|
|
|