ASG 8.201 Soft-Release

@Billybob:  8.200 is an unusual situation where a number of bugs crept into the last RC (basically the soft-release code) and were not caught by testers, both internal and external, until after the soft-release was made available.

concurrently working on seperate forks calling them x.x01 x.x02 while the original GA hasn't even been released

Based on prior experience in software development, I think that I can answer this.  With the number of issues that cropped up in the soft-release, it probably made more sense to do things this way to get the fixes out faster for those who had already installed the SR.  When major fixes are rolled into a main build, the entire code base of the build has to be retested through QA, including code unrelated to the problems, which takes a significant amount of time.  It is a much quicker process to test u2d point patches as you only need to regression test that code.  As mentioned above, the 8.200 soft-release situation was a very unusual one that hopefully won't happen again.

The internal numbering is for astaro's book keeping

This also has a big impact on how the up2date system works.  This whole 8.200 process would be smoother if the u2d code was modified to accept larger build numbers.  Then they could have done 8.200 soft-release>>8.200.1 as a u2d point patch>>etc., instead of SRv1>>SRv2>>8.201u2dSR>>8.200GA/8.201u2dGA.

@Billybob:  8.200 is an unusual situation where a number of bugs crept into the last RC (basically the soft-release code) and were not caught by testers, both internal and external, until after the soft-release was made available.

concurrently working on seperate forks calling them x.x01 x.x02 while the original GA hasn't even been released

Based on prior experience in software development, I think that I can answer this.  With the number of issues that cropped up in the soft-release, it probably made more sense to do things this way to get the fixes out faster for those who had already installed the SR.  When major fixes are rolled into a main build, the entire code base of the build has to be retested through QA, including code unrelated to the problems, which takes a significant amount of time.  It is a much quicker process to test u2d point patches as you only need to regression test that code.  As mentioned above, the 8.200 soft-release situation was a very unusual one that hopefully won't happen again.

The internal numbering is for astaro's book keeping

This also has a big impact on how the up2date system works.  This whole 8.200 process would be smoother if the u2d code was modified to accept larger build numbers.  Then they could have done 8.200 soft-release>>8.200.1 as a u2d point patch>>etc., instead of SRv1>>SRv2>>8.201u2dSR>>8.200GA/8.201u2dGA.

...  When major fixes are rolled into a main build, the entire code base of the build has to be retested through QA, including code unrelated to the problems, which takes a significant amount of time.  It is a much quicker process to test u2d point patches as you only need to regression test that code...

I completely understand and not to sound argumentative, according to Angelo,

If you want only the best and most stable things from us, don't install a soft-release! Wait the week or two for the GA push. While you might never see a difference, if its a problem for you, you have only things to gain while waiting.

 
Which suggests to me that there is indeed  code difference between soft release and GA and they are not comfortable pushing that SR to all installations by calling it GA a week later.
Also, not everyone is going to follow these message boards closely. Most people will just install the GA to get the feel for the new features and will be forced to roll back when they see huge memory foot prints and unstable http proxy. Besides, 8.201 release notes don't say anything about the number one issue that everyone is having Http Proxy run amok with huge memory consumptions forcing swap with even minor loads 

But this whole discussion is really not productive for this release and probably should be taken into consideration for future releases. Here is what I think...

1. Soft release should just be that soft release and we can go to SR1, SR2 and so on but there should only be one GA. If you deployed SR, it was with the understanding that this is not final GA and there still may be some bugs or not.

2. A GA is the final production release period. There are no dangling patches following it before its even released. There will be circumstances where even the GA will have problems for certain people and a quick up2date for that is understandable.

3. The final phase of public beta should include an upgrade phase where the new code is tested on how it behaves when upgraded from the previous production release. I think in this release specially, some of the bugs weren't seen because the SR code brought out certain bugs to the surface when people performed and upgrade from 8.103.

Thanks for listening.
Regards
Bill