Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <20130305165423.GC738@cloud-2.local>
References: <20130305165423.GC738@cloud-2.local>
From: David Nalley <david@gnsa.us>
Date: Tue, 5 Mar 2013 12:04:14 -0500
Message-ID: 
 <CAKprHVb8KgHRx1PSmRgz+C8EpnmkbvnQhk53ZWJgZrT85Rk+bg@mail.gmail.com>
Subject: Re: [DISCUSS] db changes on the 4.0.x release line
To: cloudstack-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Mar 5, 2013 at 11:54 AM, Prasanna Santhanam <tsp@apache.org> wrote:
> So this is broken off from the thread on Support Timelines for the
> 4.0.x group of releases:
>
> The issue is regarding upgrades. With the introduction of the
> DatabaseCreator I notice that we don't have to do any sort of changes
> to the baseline schema of 4.0. This is a great improvement but it only
> is enforced on the 4.1,4.2 etc releases.
>
> We have the 4.0.x release line for 4.0.1, 4.0.2 etc. There currently
> is no upgrade path from this release line to the 4.1,4.2 release line.
> The 4.0 branch also uses the older way of doing schema changes
> (create-schema.sql, upgradeXtoY.sql) which conflicts with the way the
> DbCreator works. That will have problems in upgrades of deployments
> going from 4.0.x-incubating to anything in 4.1,4.2.
>
> How should this be tackled?
>
> Since there have been few schema changes (only one) in
> 4.0.1-incubating it's probably best to port the DbCreator back to 4.0
> as well? Rohit suggested that the 4.0 branch not add db changes but I
> think it's better enforced than left as a rule.
>

So I personally am a bit irked that 4.0.1 needed a schema change, but
its our own fault, and usage simply didn't work without it. Ideally
point releases would not have a frozen schema; but it clearly it isn't
an option if we ship a release with a broken schema.

Upgrades are non-negotiable - they must work. Stranding a user on any
given release without an option to upgrade is not acceptable.

I don't personally think backporting dbcreator into 4.0 is the right
answer. If we can't get dbcreator to smoothly handle upgrades, perhaps
we need to revisit it. Handling upgrades smoothly is a requirement for
release IMO.

--David