On Thu, Jul 1, 2010 at 11:41, Philip Martin <philip.mar...@wandisco.com> wrote: > Greg Stein <gst...@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
