On Thu, Jul 1, 2010 at 11:41, Philip Martin <philip.martin_at_wandisco.com> wrote:
> Greg Stein <gstein_at_gmail.com> writes:
>
>> Dood. Re-read my email. I said interim wq items do not have to be supported.
>> Only 1.7 [release] items.
>
> So when do we autoupgrade?
>
> 1.7-dev to 1.7-dev
>
> I disabled the autoupgrade with a workqueue as it might
> break. Developers have to run cleanup with an older client. I'm not
> quite sure if you object to this or not.
It would be nice to auto-upgrade, but sure... devs can deal with this
pain. Not worried here.
It would be even nicer to fail only if *certain* items are discovered,
rather than "any" item.
> 1.7-dev to 1.7.x
>
> When 1.7.x is released the problems with old 1.7-dev workqueues still
> exist, so it doesn't seem sensible to suddenly enable autoupgrade
> unconditionally. Developers will probably still have to run cleanup
> with an older client.
Same as above.
> 1.7.x to 1.7.x
>
> The format doesn't change during a release, so we don't have to
> autoupgrade.
Right.
> 1.7-dev to 1.8-dev
>
> The 1.7-dev workqueue problems haven't gone away, and we are still
> dealing with developer working copies.
Right. Same as before. "1.7-dev with wq... would be nice to
auto-upgrade, but failing is okay".
> 1.7.x to 1.8-dev
>
> Here we could autoupgrade if we can exclude problem 1.7-dev
> workqueues. I suppose we could scan the workqueue, or perhaps we could
> bump the format shortly before 1.7.x and autoupgrade from that version
> onwards.
This is the case that I'm concerned about, and tried to clarify in my
earlier email. Once 1.7 is released, then auto-upgrades may need to
inspect/rewrite the workqueue. Hopefully, they can ignore it (much
like we ignored stale "log" files during previous auto-upgrades).
We can do format bumps or rename workqueue OP_* values to separate
-dev from -release items.
Cheers,
-g
Received on 2010-07-01 23:10:02 CEST