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
> 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
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.
Received on 2010-07-01 23:10:02 CEST