cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Wheeler <>
Subject Re: Minor releases!
Date Thu, 07 Jan 2016 14:42:37 GMT
I think that the current numbering scheme blurs the distinction between 
"major" and minor".
Without being a developer it is hard to predict the level of risk 
involved or the difficulty in reverting or even the amount of downtime 
that needs to be allotted to the upgrade.

If the dev team planning and doing the release is careful and makes a 
good decision about whether the January release is 4.7.1 or 4.8, that 
can send a strong signal to users about the risk of moving forward.

The users are captive to the Cloudstack community's willingness to 
support a February release of 4.7.2 and 4.8 if both minor fixes are 
backported to 4.7.2 at the same time as a major 4.8 version is released.

Given the fact that this is infrastructure and already very functional, 
I suspect that many people would prefer to get the 4.7.2 bug fixes 
rather than 4.8 unless they need the new features right away.
They might also prefer to wait to see how the new features in 4.8 are 
impacting the early adopters.

I think that the rapid pace of release is probably a good thing overall 
since it gets bugs fixed quickly and probably results in a less risky or 
time consuming upgrades.


On 07/01/2016 9:22 AM, Remi Bergsma wrote:
> Hi Erik,
>> And even if 4.6 and 4.7 is considered stable, and testing efforts have
>> increased dramastically, there is always a chance for regressions.
>> Just take a look at all the VR fixes that has come in after 4.6 (I am not
>> saying they are all regressions!)
> That’s a nice example of why we needed to change. The VPC refactor (that happened from
4.5 -> 4.6) introduced problems that we should have seen before (but didn’t). We should
make sure that such big changes are broken into smaller pieces and are testable. At least
we can fix them quickly now, although the PRs that are open for these issues aren’t being
reviewed and tested unfortunately.
>> I did try a 4.6 upgrade from 4.5 which essentially broke a lot of our VPC
>> usage and had to revert.
>> As a user I have to account for that before doing the upgrade, which means
>> I have to do it in a maintenance window.
>> With minor releases the risk is less, because there's no new features, just
>> bug fixes (and possible improvements?), and that is easier to account for
>> if you don't really need the new features right away.
> That’s a dangerous assumption. We upgraded from 4.4.2 to 4.4.4 and that was hell.
>> Another note on the rapid release schedule is that it stresses testing
>> efforts, you already scream about more testers, but essentially testing is
>> a 1-week job every month/release, not everyone have time and resources for
>> that.
> I referred to testing Pull Requests, so testing before stuff gets in. If we do that properly,
testing the RCs takes little effort.
>> To summarize; I (and hopefully most other users) really appreciate all the
>> hard work done by SBP, SB, Leasweb, PCextreme +++, but not everyone is in
>> the same positition to do rapid upgrades as you guys are.
> Which means we should stop it? Really, just be clear. It’s perfectly fine with me.
Just need to know what people want.
> Regards,
> Remi
>> Let me know!
>>> Regards,
>>> Remi
>>> [1]
>>> PS: At work we run multiple CloudStack powered clouds with hundreds of
>>> hypervisors so I think I know what I'm talking about.
>> Nobody questioned your skills, but they are not you. And for someone with a
>> single install with 2 hypervisors they don't necessarily have the same
>> amount of resources available.
>> -- 
>> Erik

Ron Wheeler
Artifact Software Inc
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

View raw message