cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Wheeler <rwhee...@artifact-software.com>
Subject Re: Minor releases!
Date Thu, 07 Jan 2016 17:33:06 GMT
 From a system admin position there is a big difference between 4.7.0 
and 4.6.2

Normally 4.6.2 is a minor release with no new features, no changes to 
data structures, no changes required to installation prerequisites or 
procedures unless the RM writes a big note.
Normally, 4.7.0 is a major release possibly with new features that have 
not been tried in a wide variety of hardware and software configurations 
even if it has been tested by several developers on their test setups. 
It may have hidden gotchas which may only show up in large scale 
deployment. I may need to do extensive testing before deploying.

I will generally not run any x.x.0 in production unless I am absolutely 
forced to or I don't care about reliability.
I am leery about using a x.x.0 version of a software library in 
development unless I am sure that we will be able to detect any changes 
while we are testing our software.
We might even release a version of our software with just the library 
change to see if it still works.

I understand that the numbering is out of my control but it is a signal 
from the people who are smarter than me and are intimately involved with 
the development about the risk involved in deploying the software.
It also gives a hint about how carefully the release notes need to be 
read. In major releases, there will be some reading between the lines 
required to figure out if the new feature will break something that we 
have done or is different from the environment that the developers use 
for testing.

CentOS 7 broke an amazing number of our internal practices!!! 6.4 to 6.5 
was transparent.

The differentiation of major and minor releases is also a signal to the 
Cloudstack dev community about what can be attempted in a release.
If you are working on 4.6.3, you should not be thinking about changing 
the data layer but in a 4.8, that is a valid topic to bring up.

If you do not have major and minor releases, I do not know what would be 
the best way to signal that 4.7.0 is really 4.6.2 but 4.8.0 is not the 
same as a 4.6.3.

Ron



On 07/01/2016 11:55 AM, Jeff Moody wrote:
> While the pretty pictures iare helpful, it's explaining the git
> merging/branching strategy which if I were to show to a non-
> developmentally aware coworker, they may be overwhelmed or confused by.
>
> I was unaware that 4.7.0 == 4.6.2 and try and follow development pretty
> actively.
> I also think that while the new release strategy is awesome and _I_
> love the faster releases, making this change halfway through the 4.x
> release cycle is also confusing.
>
> It might be worthwhile to make 4.8 or 4.9 be ACS 5.0 and as a part of
> the release notes make a less-technical overview of how the release
> process has changed and how releases are handled moving forward as,
> while 5.0 may not be a major feature release (following semver) it is a
> radical shift in how ACS is released to the public.
>
> For the pretty picture, I think a graphic showing the previous release
> process of branches off of branches off of branches would help provide
> a valuable comparison as to why the current process is better and more
> reliable than the previous process.
>
>
> On Thu, 2016-01-07 at 16:39 +0000, Remi Bergsma wrote:
>> This page has pretty pictures:
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+princi
>> ples+for+Apache+CloudStack+4.6+and+up
>>
>>
>>
>>
>> On 07/01/16 17:37, "sebgoa" <runseb@gmail.com> wrote:
>>
>>> On Jan 7, 2016, at 5:27 PM, Remi Bergsma <RBergsma@schubergphilis.c
>>> om> wrote:
>>>
>>>> On 07/01/16 17:22, "Rene Moser" <mail@renemoser.net> wrote:
>>>>> No, it is not the pace. You can do as many major as often as
>>>>> you want
>>>>> but if one uses this major, how long will it get minors? We
>>>>> have no clue.
>>>>>
>>>>> I understand your point completely while my argument is that I
>>>>> have to
>>>>> plan releases year by year.
>>>>>
>>>>> Under this condition I'd take the LTS of the releases, the most
>>>>> stable
>>>>> one even its 2 years old, (I have to maintain it for a year),
>>>>> not the
>>>>> latest one, for sure not a .0 release.
>>>>>
>>>>> With that mindset, there is no version for me right now.
>>>> I see your point. To me this is not a sustainable model, but if
>>>> you want to keep doing this the only option I see is finding a RM
>>>> for your specific release.
>>>>
>>>> And as a matter of fact, 4.7.0 == 4.6.2 so that .0 might be the
>>>> best .0 release we ever had. Don’t underestimate the change that
>>>> was made. Releases now build on top of each other, while that was
>>>> never the case.
>>>>
>>>> Anyway, I cannot and don’t want to convince you. We want
>>>> something different and that is fine. What I do want to know is
>>>> what others want. Because if the majority wants what you are
>>>> asking for, we should do that.
>>>>
>>> Remi, I think Rene might have a point, that while things are clear
>>> for you, the fact that 4.7.0 == 4.6.2 may be lost on other folks
>>> that are used to the old ways.
>>>
>>> Maybe we need a picture or something...
>>>
>>>> Regards,
>>>> Remi


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


Mime
View raw message