733373 - DOMi compatibility: Use '.*' instead of 'a1' syntax, to support *-aurora/beta/release (but not *-central)

Status: VERIFIED FIXED

(Other Applications :: DOM Inspector, defect)

Description

[Serge Gautherie (:sgautherie)]

ChatZilla and Venkman (already) use 13.0.*.

Any objections?

Comment 1

[Serge Gautherie (:sgautherie)]

Attachment: (Av1) Use '.*' syntax (instead of 'a1') for FF/SM/TB/Tk [Checked in: See comment 3 & 5]

(Untested.)

NB: Fennec entry (already) uses '1.0.*'.

Comment 2

[Colby Russell :crussell (no longer Mozilla-ing)]

Comment on attachment 603261 [details] [diff] [review]
(Av1) Use '.*' syntax (instead of 'a1') for FF/SM/TB/Tk
[Checked in: See comment 3 & 5]

Review of attachment 603261 [details] [diff] [review]:
-----------------------------------------------------------------

For consistency?  Okay, then.  (central has moved to 14 by now, of course.)

Comment 3

[Serge Gautherie (:sgautherie)]

Comment on attachment 603261 [details] [diff] [review]
(Av1) Use '.*' syntax (instead of 'a1') for FF/SM/TB/Tk
[Checked in: See comment 3 & 5]

http://hg.mozilla.org/dom-inspector/rev/b72c3dc211a0
Branch: DOMI_2_0_10
"13.0.* + 2.10.*"

http://hg.mozilla.org/dom-inspector/rev/f0c7b35c27f4
default
"14.0.* + 2.11.*"


(In reply to Colby Russell :crussell from comment #2)
> For consistency?

More than that: it gives us compatibility on following a/b/r branches for free.

Comment 4

[Serge Gautherie (:sgautherie)]

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey-Aurora/1331977165.1331983029.9002.gz
OS X 10.6 comm-aurora debug test mochitest-other on 2012/03/17 02:39:25

seamonkey2.10: verified.

Comment 5

[Colby Russell :crussell (no longer Mozilla-ing)]

This isn't going to work.  AMO doesn't like that.  Backed out:
http://hg.mozilla.org/dom-inspector/rev/2d1da3662aec

Comment 6

[Colby Russell :crussell (no longer Mozilla-ing)]

(In reply to Serge Gautherie (:sgautherie) from comment #3)
> it gives us compatibility on following a/b/r branches for free.

Well, we have to bump for the incoming mozilla-central version anyway, so shouldn't that have the same effect?  At next merge day, mozilla-central goes to 15.0a1, we bump for that, and nothing is lost, right?

Comment 7

[Serge Gautherie (:sgautherie)]

(In reply to Colby Russell :crussell from comment #5)
> This isn't going to work.  AMO doesn't like that.  Backed out:
> http://hg.mozilla.org/dom-inspector/rev/2d1da3662aec

ChatZilla has 14.0.*, but it was added after CHATZILLA_0_9_88_1_RELEASE,
so it can't have this issue (yet).
+
ChatZilla with 13.0.*, after bump to mozilla_14a1:
https://addons.mozilla.org/fr/seamonkey/addon/chatzilla/
ChatZilla 0.9.88.1

DOMi with 14.0a1:
https://addons.mozilla.org/fr/seamonkey/addon/dom-inspector-6622/
DOM Inspector 2.0.11

Venkman has 14.0.*, and it was added before VENKMAN_RELEASE_0_9_89,
so it should have the same issue...
Gijs, can you check whether Venkman is affected too?
+
(Maybe it hasn't been submitted to AMO yet?)
https://addons.mozilla.org/fr/seamonkey/addon/javascript-debugger/
JavaScript Debugger 0.9.88.2


(In reply to Colby Russell :crussell from comment #6)

> Well, we have to bump for the incoming mozilla-central version anyway, so
> shouldn't that have the same effect?

Not for comm-[a/b/r] which pull a specific rev/tag/branch of these extensions, to be bundled by SeaMonkey.

> At next merge day, mozilla-central
> goes to 15.0a1, we bump for that, and nothing is lost, right?

Right, this bug doesn't affect *-central, one way or the other.


Then, the solution should be a compromise (2 bumps instead of (1 or) 4):
after each cycle uplift, bump to '(n)a1' on default and to '(n-1).*' (assuming that, fwiw, we don't want to use '(n)a1' there) for what comm-[a/b/r] pulls.
Ftr, DOMi is exactly in this state at this moment.

Does everyone agree?

Comment 8

[:Gijs (he/him)]

(In reply to Serge Gautherie (:sgautherie) from comment #7)
> Venkman has 14.0.*, and it was added before VENKMAN_RELEASE_0_9_89,
> so it should have the same issue...
> Gijs, can you check whether Venkman is affected too?
> +
> (Maybe it hasn't been submitted to AMO yet?)
> https://addons.mozilla.org/fr/seamonkey/addon/javascript-debugger/
> JavaScript Debugger 0.9.88.2
> 


I am confused about what you mean by 'affected' and why I have anything to do with it. Venkman's install.rdf is kept sane; I then upload it to AMO and correct install.rdf + retry as long as necessary to get AMO happy. These changes are never committed.

AFAIK this has always been SOP for both CZ and Venkman, because if we were to let AMO dictate maxversions for our add-ons tracking trunk, we'd be wasting half our time updating those manifests all the time.

I'm not responsible for the path DOMI chooses here, that's up to the respective module owner and peers.

Comment 9

[Robert Kaiser]

(In reply to Gijs Kruitbosch from comment #8)
> AFAIK this has always been SOP for both CZ and Venkman, because if we were
> to let AMO dictate maxversions for our add-ons tracking trunk, we'd be
> wasting half our time updating those manifests all the time.

Well, not nowadays, as there's a defined point every six weeks where versions for all those products are added both on their "trunk" and on AMO. The joys of rapid release trains. :)

Comment 10

[:Gijs (he/him)]

(In reply to Robert Kaiser (:[e-mail]) from comment #9)
> (In reply to Gijs Kruitbosch from comment #8)
> > AFAIK this has always been SOP for both CZ and Venkman, because if we were
> > to let AMO dictate maxversions for our add-ons tracking trunk, we'd be
> > wasting half our time updating those manifests all the time.
> 
> Well, not nowadays, as there's a defined point every six weeks where
> versions for all those products are added both on their "trunk" and on AMO.
> The joys of rapid release trains. :)

I don't understand. How is updating these things every 6 weeks (nevermind every week) 'joyful'? It's just more work than we had before.

Furthermore, to the best of my knowledge the AMO updates are not automatic but manual, and they always use the 'a' suffix, rather than .0.* initially, judging from the rejections I saw last night when I updated Venkman. There isn't enough development on Venkman nor CZ to warrant individually checking and updating the max version for each (weekly?) beta/aurora/nightly update increment. So I prefer keeping the 'real' version numbers in the install.rdf.

Comment 11

[Robert Kaiser]

(In reply to Gijs Kruitbosch from comment #10)
> I don't understand. How is updating these things every 6 weeks (nevermind
> every week) 'joyful'? It's just more work than we had before.

Well, we default to compatible nowadays, so being late doesn't do much harm. Still, the updates in the source have been mostly done by the SeaMonkey people anyhow in recent times.
And it's surely more joyful than having releases of the different products at random non-connected intervals and be hit by them by surprise, which was the old way of doing stuff.
And in any case, .* and a1 doesn't make any difference in this anyhow, the part in front of it needs to change in that interval anyhow.

> Furthermore, to the best of my knowledge the AMO updates are not automatic
> but manual, and they always use the 'a' suffix, rather than .0.* initially,
> judging from the rejections I saw last night when I updated Venkman.

Yes, and actually, I find it a bit early to add the .* with the start of Aurora in AMO, but I guess it's OK. With the start of the Nightly cycle would IMHO be insane.

Comment 12

[Serge Gautherie (:sgautherie)]

(In reply to Gijs Kruitbosch from comment #8)
> Venkman's install.rdf is kept sane; I then upload it to AMO and
> correct install.rdf + retry as long as necessary to get AMO happy. These
> changes are never committed.

(In reply to Gijs Kruitbosch from comment #10)
> they always use the 'a' suffix, rather than .0.* initially,
> judging from the rejections I saw last night when I updated Venkman.

Thanks, that's what I wanted (you) to confirm.


(In reply to Robert Kaiser (:[e-mail]) from comment #11)
> Yes, and actually, I find it a bit early to add the .* with the start of
> Aurora in AMO, but I guess it's OK. With the start of the Nightly cycle
> would IMHO be insane.

Then let's go with my comprise: a1 on default, .* for branches.
For 3 (SeaMonkey) extensions, that's 6 changesets instead of 12.
(AMO is fine with a1 updates.)

Comment 13

[Serge Gautherie (:sgautherie)]

Attachment: (Dv1) Documentation improvements

Comment 14

[Serge Gautherie (:sgautherie)]

Attachment: (Dv1a) Documentation improvements [Checked in: See comment 16]

Dv1, with a nit.

Comment 15

[Colby Russell :crussell (no longer Mozilla-ing)]

Comment on attachment 608623 [details] [diff] [review]
(Dv1a) Documentation improvements
[Checked in: See comment 16]

Review of attachment 608623 [details] [diff] [review]:
-----------------------------------------------------------------

::: install.rdf
@@ +32,5 @@
> +         3.5 is Gecko 1.9.1
> +         3.6 is Gecko 1.9.2
> +         4.0 is Gecko 2.0
> +         5.0 is Gecko 5.0
> +         x.0 is Gecko x.0 -->

"... where x is greater than 5", and so on, please

Comment 16

[Serge Gautherie (:sgautherie)]

Comment on attachment 608623 [details] [diff] [review]
(Dv1a) Documentation improvements
[Checked in: See comment 16]

http://hg.mozilla.org/dom-inspector/rev/665cbbe3a89b
Dv1a, with comment 15 suggestion(s).

Comment 17

[Serge Gautherie (:sgautherie)]

V.Fixed