| I'd like to suggest a more 'stable' branch for us production weenies [message #5452] |
Tue, 03 September 2002 15:54  |
dtype
Messages: 11
Registered: August 2002
Karma: 0
|
Junior Member |
|
|
I'm a big fan of this software, and will continue to use it, but I'd like to request a plan for more stable development trees at some point. Having all new development happening in the same branch is a little disconcerting sometiems, and scary for those of us that value a production-ready system more than a a new feature here or there.
It seems strange to me to see severel RC releases in a row, each of which adds major features, changes in update scripts, etc. The whole point of a "release candidate" is typically to state that everything appears stable, and if no major bugs are found in the RC release, that release may be re-released as the stable next version.
Anyway, thanks for the rapid development. I know multiple branches can be a big pain and it is asking a lot. In the absence of that, a more stable RC->production release schedule might calm my nerves a little. ;) As it is, I'm not sure I see the difference between a development release, a release candidate, and a stable release, as they all introduce the same number of new features, and all typically look the same from a stability/bug point of view...
|
|
|
|
| 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: 0
|
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
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]