Breaking schema changes

[Mark Canonical Ramm-Christensen]

Agreed on both points.   Though I think we may be able to hold ground
on 2.0 for a bit without too much trouble.

If it gets to be too much trouble, I'll let Tim and John yell at me
until we relax this constraints and make their lives easier.

But we definitely DO need to test the major version upgrade stuff, and
do it as extensively as we can so we know it works in the real world.

--Mark

On Tue, May 28, 2013 at 8:07 PM, David Cheney
<david.cheney at canonical.com> wrote:
>
> On Wed, May 29, 2013 at 11:05 AM, Mark Canonical Ramm-Christensen
> <mark.ramm-christensen at canonical.com> wrote:
>>
>> Mostly, it is to combat the perception that we are making breaking changes
>> at a rapid pace, and therefore aren't stable enough for real world use.
>>
>
> Understood, although I repeat my assertion that we should do several major
> upgrade actions (even if they do not consitute a visible major upgrade from
> a numeric point of view) to iron out the process.
>
>>
>> Secondarily, it is so that we are aware of and controlling when backwards
>> incompatible changes land in trunk, and are preserving the ability to
>> release 2.0 as an important milestone (it's only psychological, but that
>> does not mean it's not important).
>
>
> I have no comment on consecutive version numbers other than they are present
> an additional artificial constraint on an already difficult problem.