incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <bhais...@apache.org>
Subject Re: [DISCUSS] Support lifetime
Date Tue, 05 Mar 2013 11:03:35 GMT
In minor CloudStack version we OUGHT NOT change the DB schema, maybe
we should not even change the DB version, comment?
So, all minor version should have version info in DB as 4.0 (for 4.0,
4.0.1 and 4.0.2) and 4.1 (possible future 4.1.xs) etc.

Regards.

On Tue, Mar 5, 2013 at 4:25 PM, Prasanna Santhanam <tsp@apache.org> wrote:
> On Mon, Mar 04, 2013 at 09:53:36AM -0500, Chip Childers wrote:
>> On Mon, Mar 04, 2013 at 05:34:41AM -0500, Sebastien Goasguen wrote:
>> >
>> > On Feb 28, 2013, at 1:21 PM, Joe Brockmeier <jzb@zonker.net> wrote:
>> >
>> > > On Wed, Feb 27, 2013, at 03:00 PM, Chip Childers wrote:
>> > >> I stated my opinion on this previously [1], but for the record again:
>> > >>
>> > >> I would suggest that we only do bug-fix releases for:
>> > >>
>> > >> - The latest feature release of our active major version number (i.e.:
>> > >>  4.x)
>> >
>> > To make sure I get this right:
>> >
>> > So Once we release 4.2 we will only bug fix 4.1 and stop bug
>> > fixing 4.0 ?
>>
>> That's what I'm proposing, yes.
>>
>> >
>> > >> - The latest feature release of our last major version number (doesn't
>> > >>  exist today, but will be 4.x when / if we bump to 5.0)
>> >
>> > Once we jump to 5.X we will bug fix the latest 4.x release (if
>> > it's 4.2, we will stop bug fixing 4.1) ?
>> >
>>
>> That's also what I'm proposing, yup.
>>
>> > The really crucial part for me is to make sure we have a really
>> > solid/tested upgrade path. We cannot leave anyone out in the cold
>> > of a "unsupported" release.
>> >
>>
>> Indeed.  Upgrades remain critical to this project.  We need to
>> constantly ensure that we have upgrade paths available from any version
>> to the latest version.
>>
>
> The context of upgrades came up on IRC today - it looks like the 4.0.x
> line is still using the old method of doing upgrades ie w.o.
> DatabaseCreator. So if at some point the 4.0.x line alters schema
> upgrading that deployment is going to run into problems because it
> doesn't conform to the dbCreator's way of doing things.
>
> The 4.0.1-incubating release only had one database change
> (91a9cce35a67350c856bb10e5fe36f4bf5bac029) so it's probably a good
> time to decide on a strategy for upgrades from the 4.0.x line to the
> 4.x-5.0 line.
>
> --
> Prasanna.,

Mime
View raw message